Experiment: Measure Lead And Cycle Time
How lead- and cycle time are incredibly helpful metrics to drive change where it matters
In our book — the Zombie Scrum Survival Guide — we dive deep into what causes Zombie Scrum; something that looks like Scrum from a distance but lacks a beating heart. We also offer 40+ experiments to recover from Zombie Scrum. This experiment is one of them. Download the paper “10 Powerful Experiments to Overcome Zombie Scrum” to get even more inspiration on how to fight Zombie Scrum.
Zombie Scrum flourishes in environments where people are unaware of how much time items from the Product Backlog are “in progress” somewhere in the organizational pipeline. Product Backlog items are only valuable when they are released to stakeholders. Not releasing them early is essentially a form of waste, as those items have to be tracked, managed, and coordinated throughout their lifetime in the pipeline.
This experiment is all about creating transparency around this type of waste with two related metrics: lead time, or the time that transpires between when a stakeholder request enters the Product Backlog and when it is fulfilled to that stakeholder through a release and cycle time, or the time that transpires between when work is started on an item and when it is shipped. The cycle time is always a part of the lead time. Lead- and cycle time are great measures of agility; the shorter they are, the faster you ship and the more responsive you are. In environments with Zombie Scrum, these timings are much longer than in environments where Scrum works well. The picture illustrates this point.
Required skill
This experiment requires some data gathering, calculations, and patience. Nothing too fancy.
Impact on survival
Ultimately, cycle and lead time are your incredibly helpful metrics to drive change where it matters. Expect a boost in survival!
Steps
To try this experiment, do the following:
- In order for this experiment to work, you need to track three dates for every item on your Product Backlog that you want to analyze. You can track it for all the items or for a sample. For each item, add the date of arrival. This is the moment when an item is added to the Product Backlog. If a lot of time usually transpires between the identification of the item and when it ends up on the Product Backlog, track the moment the item was identified instead for a more accurate picture. Whenever an item is put on the Sprint Backlog, put the current date on the item to track when the team started to work on it. Finally, put the date on the item when it is made available to stakeholders. This is the moment of the actual release, not the moment when it is considered “potentially releasable” by a team.
- Whenever an item is released to stakeholders, calculate both the lead and the cycle time in days and keep it with the item. Remember that the cycle time is the time in days between the moment that the team started its work on it and the release date. The lead time is the time in days between the date of arrival and the release date. Do this for a while so you have at least 30 items, where more is statistically better.
- Calculate the average lead time and cycle time in days and write them on a flip. The lead time is “the time stakeholders have to wait for us to help them” and cycle time is “the time for us to get something done”. If you keep tracking this metric, you can demonstrate improvements (or declines) over time. Most of the experiments in this chapter help you drive both metrics down.
- Use the cycle and lead time as input to Sprint Retrospectives and organization-wide workshops focused on reducing lead and cycle times. What actions can be taken to shorten both? Who needs to be involved to do so? Where are impediments making it hard to shorten the lead time?
- Recalculate the cycle and lead time every Sprint (or even sooner) to monitor progress and identify further improvements.
Our findings
- Incoming requests from stakeholders may be big enough to warrant refinement. In that case, maintain the same arrival date for the smaller items coming out of this refinement.
- Some Scrum teams require other departments, teams, or people to do additional work before something can be released to stakeholders. For example, another team may need to perform Quality Assurance, a security scan, or perform the actual installation. In all cases, the release date of an item remains the date when that item is actually made available to stakeholders. Using the date when your team hands-off work to others is a great way to fool yourself (and the organization) that things are going well.
- Calculating an average cycle time is a rough indicator that we included for the sake of simplicity. A more precise approach is to use scatter plots and confidence intervals.
- Don’t worry about when the items you picked are not the same size. Since we’re working with averages, differences even out. Just make sure that the work is small enough for (roughly) a Sprint.
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.
