queue time — foundation for predictability
To be able to estimate for release planning, you have to come to grips with queue time. With story estimation, you have to work out the range of effort likely needed to implement the task, taking into consideration it’s dependencies. But effort estimation can’t tell you how much time the work will sit in state transitions waiting for attention. To understand queue time, you have to reason about a different set of problems.
Time is the fire in which we burn.
— Gene Roddenberry
If someone explained commuting time in terms of driving skills, you’d immediately point out that it matters little how good you are behind the wheel when you’re sitting in a queue. If you leave a different time or take a different route, that could significantly impact the outcome, but you’d have to reason about different problems than driving skills.
Conflating effort and queue time estimation happens all the time when development team are asked when something will be done, when what is really meant is: when will be ready to go live.
That’s not an argument against estimation; it’s a recognition that different classes of problems need to be estimated in different ways. Most discussion about estimation is about appraising the work itself, as we have done in the preceding posts. All of that is a good foundation, and fundamentals such as understanding the concept of measurement and methods of measurement apply to release planning as well, but in different ways.
Release planning comes down to a question of throughput: if stories going into work are completed at a predictable rate, then you can estimate for release planning without even taking into consideration the story estimates. David Anderson makes that argument in his books on Kanban, and going down that path; we find it becomes more a conversation about the process than it is about estimation. Process and estimation are very tightly bound, and we’ll look at that in more detail in a moment, but first, let’s go straight to the heart of the matter: decomposition.
Properly decomposed stories don’t come out of a single meeting, they are the result of a process adopted by and followed by the development team. When improper decomposition results in blocking dependencies, rework and other delays, the problem is not in the work, but in the process by which prepared and committed the story to work. If we’re concerned about making delivery commitments, then we should be focused on throughput, and if we focus on throughput, we should be concerned about the process.
Story Points and Velocity
Story Points are the basis of a clever parametric estimation technique useful for separating time and effort. Velocity is a scheme using Story Points to calculate the team’s progress across Sprints using some [sketchy math.]
Calculating Throughput In Kanban
You could say that Kanban is designed to give you throughput “out of the box.” The core principle of Kanban is to constrain the simultaneous work in progress (WIP). By limiting WIP, you dry out queue time. In contrast to Kanban, when the emphasis is on capacity utilization, whenever work in progress is blocked, then new work is brought into play to maximize utilization, pending resolution of the blocking issue. There are many aspects of this dynamic which are attractive to discuss, but the on that is relevant here is how it degrades our capacity to understand throughput. Because Kanban forces the resolution of blocking issues in real time, it maintains the integrity of the record of the work time.
If WIP limits are properly managed, Kanban gives the means to calculate throughput easily:
The line of each element, Lead Time, Work Time and Flow Efficiency indicates the arithmetic mean of that value. Thus, the Mean of Flow Efficiency equals the Mean of Work Time divided by the Mean of Lead Time multiplied by one hundred percent.
The chart below shows Little’s Law visualized on a graph of work committed and work delivered over time.
The point is that you can skip a lot of headache of release planning by adopting a process that is designed to yield the information that is most important to know where you stand concerning release planning. Instead of trying massage effort estimate roll-ups padded with guesses about queue time, in Kanban, you focus on managing the work.
Predictability builds and holds trust, a core Agile value, better than does delivering more with less reliability.
— David J. Anderson
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.