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.
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…
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.
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!)
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.
- 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.