Agile Metrics - Lead And Cycle Time
Last time we looked at the most common question we get from management -
What metrics will I get?
And saw that our usual answer - velocity - really isn't very good at answering that question. It's really only designed to be an internal measure for a single team. You can't use it to compare teams. I mentioned that Cycle Time is a much better metric to use for this sort of question, so let's take a look at Cycle Time. We will also look at its cousin - Lead Time.
Cycle time is essentially, the time a team spends completing a story - the clock starts when they start work on it, and it stops when it's done. So if a team starts a story on Monday and it's done Friday, the cycle time is 5 days. Individual cycle times are fairly meaningless (like individual velocity measurements) but over time the team will establish an average cycle time. Lead time, on the other hand, counts from when the story enters the team's backlog to the time its done. Lead time - cycle time = the time the story spent sitting around in a queue waiting to be started. Together these two metrics can answer management’s burning questions and even better, we can use them to drive some helpful behaviours.
The beauty of Cycle Time is that it measures something real. A story is something of value so the story cycle time measures that rate at which the team delivers value. So if a team reduces its cycle time, it starts delivering value faster. It's not like velocity, where a team can double their arbitrary story points and appear to have doubled velocity. If a team reduces their cycle time they really have started delivering faster.
There are only three ways for a team to reduce their cycle time -
Get better and faster at working so we deliver faster
Reduce Work In Process
Make the batch size smaller
All of these are good things. If a team gets better and faster at delivering (remembering that it's average cycle time, so they are getting better at delivering faster consistently, not just as a one-off), good. There's really no downside to that. This isn't something they have gained, it's a real, sustained improvement.
If they reduce cycle time by reducing WIP, again, good. No downside. The relationship between the number of items in a queue (in this case the team's WIP queue) and the time it takes for items to traverse the queue is well-established mathematically through queueing theory. I won't go into detail because I just felt half my readership fall asleep there, but trust me, reducing the number of things in progress must lead to a reduction in cycle time (if the batch size stays constant). The team has started starting less and finishing more. They are focusing on delivering the highest value items in their backlog as fast as possible and not letting a bunch of extra work get in their way.
Likewise with batch size. If they slice their work into smaller chunks, then, thanks to queueing theory again, they will deliver those chunks faster. As long as the chunks still deliver value, no downside. Small batches have a shorter cycle time than large batches. Management should be driving teams to reduce their batch size as small as possible to enable short cycle times and therefore fast delivery of value. A lot of teams think that this is a way to game the metric -
Team - Ha - fooled you.. all we did was cut the stories in half!
Management - Ha - fooled you back. That's exactly the behaviour we were trying to drive!
This isn't a metric the team can game. As long as the Product Owner keeps the team honest about stories delivering value, any improvement in cycle time can only have come from a real improvement in one of those three things.
It's the same with lead time. Since Lead Time = Cycle Time + Queue Time, the only way to reduce lead time is either to reduce cycle time (see above) or reduce the length of the queue. Both of those are good things.
The best way to reduce the length of time things spend sitting in queues is to WIP limit the team's backlog. Don't put 400 things in there. Changes are, number 399 will never get done, there will always be something more important above it. Limit the queue to the top 50, or better still the top 10 things the team need to get done. You will cut down the amount of time the team spends managing their backlog and improve lead time all in one.
The best thing about lead and cycle times are that they are super easy to measure. All you need to do is mark on the card, the day it entered the backlog, the day the team started work (in a scrum team that's usually the day they planned it into the sprint) and the day it gets accepted as done. Backlog->Done = Lead Time, Started->Done = Cycle Time. Easy. Most agile tools will record these for you so if you use an electronic tool for this, you probably already have these metrics sitting there for free.
Lead and Cycle times are the best metrics for managing agile teams (and frankly, for measuring any team). A simple chart of average cycle & lead times month by month or week by week will show Management how fast the teams deliver value and will show whether they are improving, steady or declining. Once Management know the lead and cycle time they can start to forecast - "I know that if I put this thing on the team's backlog, on average it will take X months to get done. The team say they have started work on that feature, I know that on average I will get it in X weeks time".
We can do even better than that though, and borrow a technique from statistical process control called the control chart, which can tell us a whole bunch more about our process. I'll look at them next time.