KPI cycle time and lead time with scrum (kpi less well explained / no concrete examples available)
Hello Scrum Masters,
I have just finally obtained my PSM 1 certification, it was quite complicated, I had taken it once in English and I did not understand anything, then I added plug-in to translate the questions and it was much simpler ... however the unresolved questions remain the same for a new scrum master. especially concerning certain KPIs like cycle time and lead time.
In real life, by whom are calculated and reviewed? We still use the paper, feather and the excel table or there is software to do this?
The explanations that I found are very blurry and totally theoretical, concrete examples on line with the use of this two metrics in scrum are non-existent, could someone help me with a concrete simple examples (Scrum / Kaban board and the Cycle Time calculation details) or a good link to finally understand this....
In detail I would like to know if in a cycle time:
we count the day / man actually worked or the calendar days :
exp: 1 Sprint of 2 weeks for 3 developers in the team we will take for the cycle time
• number of calendar days: 14 days
• number of days actually worked days 10
• number of man days actually worked (10 x 3) - 2 days of absence of a developer = 28 days
(I have some problem here because for example the number of man/days actually worked is taken into account for the velocity planning metric)
In detail I would like to know if:
exp: 1 Sprint of 2 weeks for 3 developers in the team we will take for the cycle time
• number of items in done for dev team : 8 items
• number of tasks done dev team: 8 items each composed by 3 tasks: 8 x 3 = 24 task done
Thank you very much Andréa
• number of calendar days: 14 days
• number of days actually worked days 10
Consider it from the perspective of stakeholders. Did they wait 14 days before value was delivered, or 10?
exp: 1 Sprint of 2 weeks for 3 developers in the team we will take for the cycle time
• number of calendar days: 14 days
• number of days actually worked days 10
• number of man days actually worked (10 x 3) - 2 days of absence of a developer = 28 days
This sounds more like a measurement of capacity.
Cycle time measures the actual time passed from actual work beginning to the point where the item is delivered.
Lead time measures the actual time elapsed between the inception of the idea to the time it is ready for customer use. Lead time includes the period before the development team starts to code and after the push to production which could be marketing or sales activities.
Throughput measures the number of items that pass through your process in a specified time interval.
Capacity is the measurement of expected units of work available to allocate work into. This is what your formula calculates.
Velocity is usually done by totaling story points or estimates accounted for during a specific range of time. It can be useful to a team to estimate if they feel they have a body of work that they can accomplish during a specific range of time. But it is a leading indicator based upon estimates.
The two books listed here (https://actionableagile.com/resources/publications/) will help you better understand the use of throughput, cycle time and lead time.
Cycle time and lead time are flow metrics, and describe the total elapsed time for an item to move through a workflow.
Measuring the elapsed time, rather than the total amount of time spent on particular activities is important for optimizing flow.
Imagine you manage an airport, and you want it to be possible for 95% of passengers to be able to make it from the front door or check-in desk to their departure terminal within 45 minutes. Let's consider this the lead time.
The amount of time they spend walking towards the gate is probably not the defining factor in whether they achieve this. Simply put, you do not want 45 minutes to elapse before they reach the terminal.
So rather than focusing on the time they are active, you will also want to understand what other things slow them down. You might even visualize the flow as:
- Walking to departures
- Scanning boarding pass
- Walking to security check
- Undergoing security check
- Walking to passport control
- Undergoing passport check
- Walking to the terminal
- At the departure terminal (Done)
At this point it becomes clear that there are several points where the passenger is likely to be in a queue.
As part of a continuous improvement process, you might inspect what happened for the passengers with the highest lead time, because this may well be where the biggest gains are to be made.
It may turn out that on Sunday afternoons, the security check is slow because of a long queue, and the best corrective action might be to invest in equipment, staff, or the processes being followed.
If this is a success, it should eventually show in the metrics.
As part of its own continuous improvement, the security team might primarily be focused on its own cycle time of getting the passenger through security as quickly as possible; but there is a risk that this leads to local optimization, where this team makes changes to shorten its cycle time, even if it slows down the passenger overall.
If the security team instead also consider lead time, they might come up with other innovative approaches, such as allowing passengers through the door that provides the quickest route to passport control, or even advising people to have their passports open before they reach passport control.
I hope this real world example helps you consider it in the context of a Scrum team that develops software, where the flow might be:
- Defining opportunity and perceived value
- Ready to identify solutions
- Identifying and refining solutions
- Ready to start development
- Coding
- Ready to deploy
- Deploying
- Deployed (Done)
Again the even numbered steps could be stages where queueing takes place (waiting for someone to pick up the work), and depending on the structure of the team(s), they may be focused both on the cycle time for part of the flow, or the lead time.