Cumulative Flow Diagram and WIP limit

One of my teams works with Scrum. We usually take about 5-6 stories into a sprint.

We noticed, that sometimes we had a problem with finishing all the planned stories, even though our estimations did seem to be correct. It might be quite normal for Scrum teams, but we decided to rely on data to tell us what we might be doing wrong.

Tracking tasks

As 5 stories is not that much data to track, we decided to track the flow of all tasks instead, ignoring the actual stories for this experiment. Every day we were noting down how many tasks were residing in each column of our physical story board, which looks more or less like this:

To do Doing To review Reviewing Done

Cumulative Flow Diagram (CFD)

At the end of the sprint we illustrated what was happening every day by using Cumulative Flow Diagram. To our surprise it looked pretty bad! We didn’t even realise that we were going nowhere while days were passing by.

The blue part of the diagram (‘Done’) was supposed to go up diagonally during the sprint, but almost didn’t move. The purple part of the diagram (‘To do’) completely dominated the graph. Not good…

Sprint Z
Cumulative Flow Diagram of a bad sprint

WIP limit

We realised, that we were working on 11 tasks at the same time, while there were only 4 of us. By ‘working’ I mean all tasks that were neither in ‘To do’ or ‘Done’ sections. At this point we concluded that we needed a WIP limit. Starting from next sprint, nobody was allowed to start a new task, if there were 5 tasks already in progress (between ‘To do’ and ‘Done’).

It was a bit annoying at the beginning, but somehow tasks got reviewed much quicker this way, as they were blocking access to new work. Also, any problems that were normally discovered at the end of the sprint were now visible much earlier in the process.

Success!

Just a few sprints later we were fully up to speed and tasks were flowing really quickly.

Have a look at the CFD of the following sprint:

  • The ‘Done’ part goes up diagonally, almost with a constant speed – we are continuously delivering!
  • There is a step in the ‘To do’ area because we needed to add more stories in the middle of the sprint, as we were moving faster than expected.
  • The tiny section between the blue and purple areas means that the number of tasks in progress at any time was minimal (WIP limits!)
Sprint H
Cumulative Flow Diagram of a good sprint

Good WIP limit value?

So what is a good limit for work in progress? That depends on the size of the team and on how much you want the team to do pair programming. Initially we set our WIP limit to 5 tasks for 4 team members. Today, having 8 people in the team our WIP limit is 7. That is to ensure we don’t work in little silos.

Key benefits

  • A CFD shows exactly what happened every day, while we (humans) wouldn’t remember the sprint this way.
  • WIP limits mean less work started, more work finished.
  • WIP causes work to be reviewed quicker, which highlights any issues earlier in the process.
  • WIP helps to decrease context switching, which in effect makes us more efficient.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s