Managing WIP with Scrum

Recently I’ve mentioned, both on groups and blog posts, the fact that many limiting Work In Progress in reserved for those taking on Kanban Software Development.

In this post I’d like to share a couple of the techniques / approaches that I use in managing WIP within a Scrum framework. These tools may be useful to you in order to improve an existing Scrum team or as a step in moving towards Kanban (see also Scrumban by Corey Ladas).

Daily Management

Members of an agile team should be empowered and trusted to work on the right thing. This may be helping out a colleague or fixing a broken build as well as building new features.

In order to encourage the right behaviour I propose the following filter to new teams. When looking for the next task to work on:

  • Is there anything I can do to assist a colleague in moving a high priority task to Done?
  • What is the highest priority task on the board that I have the skills to take on?

This has the effect of keeping the task in progress to a minimum as well as weighting the teams effort towards the top of the board (i.e. towards higher priority stories).

Some of the teams I have coached have had a code review column that development tasks must flow through, reviewing some code would be one way of assisting in getting to Done.

The effect of this approach is to minimise the stories in progress, maximise the chances of completing the higher priority stories in the iteration, encourage swarming over tasks and stories.

Project tracking

Many Scrum teams use burn down charts. Consider using a burn up chart, this provides visibility into changes in scope as well as room for further improvements as you’ll see in a moment. By tracking two lines representing scope and done we can our progress towards some milestone. In the example below blue shows the known project scope and green is work done by the dev team.


It is common to do some early analysis work before an iteration to ensure that the acceptance criteria of a story are known before the sprint planning meeting. We want to ensure that we don’t over invest in this analysis work retaining a healthy buffer of stories ready for development.
This part of the scope that has been analysed can be shown on our burn up chart, yellow in the example below. Here we can see where analysed work is building up.


Of course if we are doing this we may also add an analysis column to the task board along with a ready for development column.

Another category of work common in Scrum teams is post iteration testing. After the demo we hand off work to a QA or UAT group that validate the requirement has been met. By recognising this work we continue to expand our view along the value stream.
Below I show in red the work that has been accepted by QA. This demonstrates a problem in the system which was not made visible by the original chart. We can see that work that is developed but not tested is building up. If we care about WIP and cycle time then this is a problem, also if we care about project success we should consider this to be a build up of risk.


A final line could be added to show the deployment of software. A delay in deployment can mean missed revenue earning opportunities as well as a missed opportunity to learn and react.

I use these type of charts (Cumulative Flow Diagrams) as an aspect of project reporting in order to expose a more complete view of the development process beyond the confines of the Scrum team.

Also, where applicable I will augment the task-board with these extra states to show more project context to the team.

[Post to Twitter]

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>