Work in progress limits inside iteration
In iterative software development methods like Scrum people limit the work in progress by selecting the amount of work they take in when iteration starts. This works well when the amount of the work that has been selected fits in iteration so the work gets completed. What to do when people select constantly too much work to the iteration and at end of iteration there is huge amount of work in progress and almost no work is in a state that it could be called completed?
In this situation one can try to limit the work in progress during the iteration. This happens so that there is only limited amount of requirements that can be worked simultaneously. Requirements that are under work must be completed before new requirement can be started if work in progress limit has been reached. E.g. we can limit the work in progress by setting limit of two requirements in progress at any point during iteration.
I have noticed that having explicit work in progress limits that all people agree on works much better than good intentions that we finish the requirement before moving to the next one.
There are 1 Comments to "Work in progress limits inside iteration"
Thanks, Ran, for a good post. When working with Craig Larman, he mentioned one technique for doing this. In Sprint planning, teams will physically separate tasks for each requirement: one flip-chart paper for each requirement.
During the Sprint, teams will only have one flip-chart visible, other are hidden (e.g. upside down on floor). Only after req. #1 is done, the team is allowed to turn next paper visible.
This creates a physical token (flip paper) which helps teams to remember the rule.
I tried this once and team failed: they had too many “general tasks”. Obviously they had issues with backlog, and those came visible when they were forced to “work on one requirement only”.