TL:DR Limiting WIP has an exponentially positive effect on reducing Lead Time.
User story lead time was recently added to my client’s reporting system, to be used by Scrum teams. Story Lead Time (LT) is the average number of days from the story creation data to its finish in a completed sprint, meaning LT = (Completed Date - Create Date).
Some of you might be thinking, "So what? Sounds like a metric that a manager can use to make me work harder." If that's the way you (or your manager) think about metrics, this is likely to result in very unfortunate behavior (see Goodhart's Law, Campbell's Law, and the Hawthorne Effect).
To wit, if my goal is to reduce Lead Time, I need the Create Date to be closer to the Completed Date. There are many ways to do this, but two that I have heard already this week are:
Have a "shadow backlog" outside of Jira. When the squad is ready to work on the story, add it to Jira. Voila!
Compromise the Definition of Done, specifically sacrificing quality and cleaning up Technical Debt in a "hardening sprint". Ugh!
Of course, neither of these tricks will actually reduce the Lead Time. They are designed to game a system that doesn't exist. It is a complete misunderstanding of the purpose of measuring Lead Time.
The purpose of measuring Lead Time is to shorten the customer feedback loop. When we say that "lead time starts with a request from a customer and ends when the value is delivered to that customer", we remind ourselves that our purpose is to deliver value to customers and to get their feedback so that we can deliver even more value to them. The purpose of delivery is learning, and the more frequently we deliver, the more we learn. Thus, shortening the feedback loop (i.e. lead time) will increase our learning.
If you're still with me, your next question might be, "How do we shorten our Lead Time without working harder or faster?" To answer this, it is important to understand what Lead Time is, especially the law that governs it: Little's Law. I won't bore you with the origin of Little's Law in queuing theory, but here's a decent primer if you are so inclined. I'll keep it simple for our purposes.
Little's Law in software development says that
Lead Time = WIP / Throughput
WIP (Work in Progress) is the number of items being worked on by the team. In software development the unit of measure could be user stories.
Throughput is the departure rate and in a stable system it is the same as the arrival rate of Little’s original formula. An example of Throughput is five user stories per week.
Using that formula, there are two ways to reduce the Lead Time:
Increase the denominator (throughput) by delivering more things faster. Presumably you are already working hard at a sustainable pace, so there probably isn't much we can do about the denominator.
Decrease our numerator (WIP). The simple act of doing one thing at a time will reduce your Lead Time. The best part is that the relationship, while appearing to be linear, is potentially exponential!
Again, I won't go into the details of the high cost of task switching. Suffice it to say that for every task or story you have in progress at a time, you are losing gobs of throughput(!) every time you switch between them. Therefore, if we reduce our WIP, we are having an indirect (but very real) effect on throughput. In other words, reducing WIP is a way to positively affect our numerator and denominator at the same time, thus reducing our Lead Time!
Let me know in the comments what metrics you use to signal a need to change the way you work.