A prominent agilist posted a question on Twitter that lead to a long discussion: “Can Scrum teams use velocity as the WIP limit for a sprint? Will it take them closer to pull-based planning?”

Several replies quickly followed from many in the Kanban community, pointing out various problems:

Different units. WIP limits are measured in the units of work (e.g. the count of work items), while velocity (and throughput) are measured in terms of amount of work completed in a unit of time (e.g. items per week). Therefore, you cannot compare them as numbers; it’s like comparing kilometres and kilometres per hour.

Constraint on throughput. Using velocity (the average number of stories or story points the team completes within a sprint) as a limit of what they commit to in the upcoming sprint would effectively serve as a self-imposed constraint on throughput. Such constraint has nothing to do with limiting work-in-progress. Kanban actually suggests the opposite as it sets balancing capability and demand as a goal. If throughput can serve as a measure of capability in a given context, then, to the extent that balancing capability and demand involves growing capability, we want to increase throughput, rather than limit it. This can be achieved, indirectly, by limiting work-in-progress, which is, again, different from the work completion rate.

The discussion served as another reminder that Kanban remains in a blind spot of the Agile community. Agile gurus cannot be counted on to figure out some Kanban basics while Kanban community holds frequent, intense conferences where they discuss more complex stuff. But let’s save this for another day and see how this discussion can help real-world teams.

Just Add Variability

Scrum team using velocity as a WIP limit guideline – effectively not limiting WIP

Let’s say a Scrum team decided to set their in-sprint work-in-progress limit equal to the their velocity number, that is the number of stories they’ve delivered on average in each sprint. This means a WIP limit of N and an average of N stories delivered per sprint. Assuming a somewhat stable system, we can apply Little’s Law and estimate the average story’s cycle time to be equal to the duration of one sprint. Now, if there was absolutely no variability, all N stories would be done exactly in one sprint. However, even minimal variability will ensure that about half of the stories would be done by the end of the timebox. (Reference: Donald Reintertsen, Managing the Design Factory, page 18).

This must sound very familiar to mainstream Scrum adopters. A standup meeting goes like this: “Yesterday, I took part in sprint planning and started working on story X; today, I’m working on story X and nothing is blocking me”, “Yesterday, …I started working on story Y”, “…story Z…” And then the team delivers half the stories they committed to.

Lean Workflow

Lean workflow in-sprint with a WIP limit based on understanding of Little’s Law and effects of variability.

Lean workflow – a very simple way to combine Scrum and Kanban – involves limiting work-in-progress within each sprint. (Reference: William Rowden, Lean Workflow: A Parable in Pictures.) It has the effect of shortening the story cycle time and the team can potentially choose it such that the upper control limit of the cycle time fits within the timebox. It follows from the variability considerations presented above that the in-sprint WIP limit should be a fraction of the number of stories planned for the sprint. In the duration terms, the expected story cycle time should be a fraction of the sprint length.

XP and Pair Programming

It is my observation that people who came to Agile many years ago from eXtreme Programming are generally much better than today’s mainstream Scrum adopters at creating well-performing teams and avoiding dysfunctions. By prescribing pair programming, XP takes an approach which can half the work-in-progress and the cycle time, accomplishing essentially the same goal as the lean workflow.

Emergent Practices

It is clear that, after setting the “lean workflow fraction” to 1/2, XP practitioners didn’t stop there. Seeing something that worked, extreme programmers found more ways to slice user stories into even smaller pieces of value, creating techniques such as Product Sashimi and Elephant Carpaccio.

On the other hand, mainstream Scrum teams not practicing lean workflow, whether in its “mathematical” or XP form, may see the opposite practice emerge – aggregation of smaller, related stories into something “doable” by one programmer within two weeks. “I’m working on the FooBar Service, that’s my story for this sprint.” (Where there is one obvious way to slice the FooBar Service into at eight user stories and slightly less obvious ways to slice it into more than eight.) Honk if you’ve never heard this!