When I started to use the Kanban method there were two measures: lead time and throughput. I’ve already written about lead time in a previous post so let me talk about throughput now: it tells us how many work items we finished in a given time frame. For example, 10 work items a week, or 34 features a year. I had been measuring both for a while but about a year ago I changed my approach regarding throughput. First, it wasn’t really helpful. I knew how many work items we did in a week but that didn’t tell us much about how the team was actually performing. An increase in throughput doesn’t necessarily mean that the team is improving (can do more work in the same time frame). It can also mean that they are under lower or no pressure and they can finally finish the work items they piled up in their inventory. So, they appear to be performing better, but in fact they aren’t. Second, the demand in software development is not quantitative like in car manufacturing where throughput originates from. If the market demands 10000 cars a year the factory has to have a throughput that is equal or slightly larger than 10000 cars per year. In software development we have to deliver the feature or the functionality the customer can use, so delivering 100 features doesn’t make sense to me. So, I decided to call throughput a secondary measure and use it differently than before.
I cannot really do anything with my issue of quantitative demand because that is not natural in software development unless you are paid by the number of delivered features. However, I can use the throughput to see how a team is doing by simply showing the demand (input) next to the throughput (output). The demand can come from outside and inside of the team. Outside is when the team gets the work from somebody else, inside is when the team plans the work themselves.
Let’s take as an example a team planning one week ahead. The chart on the right shows how they are performing week by week. As you can see they finish more and more work items (increase in throughput) week by week but they never manage to satisfy the demand that they are creating themselves by planning. This team needs a break and re-evaluate their planning process. It is clearly visible that they cannot deliver the amount they are planning, and most probably they have a huge internal backlog somewhere where the planned but never delivered work items are staying. What they should do is clean up this inventory and during the next planning session they should stop at the number of cards that equals to the throughput of the previous week. When their throughput exceeds above the demand several times in a row they can change this approach and take more work items, but as soon as the demand exceeds higher than the throughput they should check their planning process again.
comments powered by Disqus