Friday, May 6, 2016

Work In Progress Limits

One of the problems I've seen in dealing with new Scrum teams is work items finishing on the very last minute of the very last day of the sprint. I refer to this phenomenon as 'falling off the cliff burndown'. Here is one example:



As you can see in the burndown report, most of the stories are finishing on the very last day of the sprint for this team.

There can be several reasons why this is happening. From what I have seen, 2 reasons stand out:
  1.  The story size is too big, or 
  2.  The team is starting stories but not finishing them

WIP Limits help you solve the second problem. Enforcing WIP limits forces your team to "start finishing". This is important, because we don't want to find out on the last day of the sprint that a few things can't be finished. Good Agile teams are predictable throughout the sprint, and raise the flag early on work items that won't finish by the end of the iteration.

If your team is struggling with work items finishing on the last day of the sprint, try applying WIP limits. Start off with a lower WIP limit number, say 2 or 3. Applying a WIP limit of 3 to your "in progress" column means that only 3 work items can stay in that column at a time. The team needs to swarm on those 3 items, and get them finished, before they are allowed to start new work. 

Raise or lower the WIP limit as needed, based on conversations in retrospectives. Ask your team members to respect the WIP limit. A good real life examples of WIP limits is - Cars on highways tend to be able to go at the speed limit if the number of cars is less. Jam packed highways don't usually have cars going at high speeds. 

One of my new favorite adage about WIP limits is that they help you stop starting, and start finishing.


Rate this post!