A lot goes on during a sprint, most of which can be observed by being in the presence of the team. Sometimes though its useful to capture workflow for reflection; information can help identify, support or discover patterns in the workflow which is not always visible when you are close to the problem. This is where cumulative flow diagrams (CFD’s) can be useful.
Using CFD’s to support discussions and the occasional retrospective, can help identify patterns within the team and are a useful learning aid when trying to encourage the team move more towards cross-functionality.
Below I have provided some examples and what they show in relation to workflow.
Firstly lets take a look at the good old standard Sprint Burndown.
Example Sprint Burndown Chart
If you have been using Scrum this will look very familiar. The burndown shows whats been delivered as ‘Done’ and how much work remains each day ( 1 to 10 ), which is updated throughout the sprint. This gives a clear understanding how much business value has been complete and is a good indicator whether the team are on or off track with their sprint goal. In reality you’ll never really get a perfect line as ‘expected’ as stories are structured in stepped point scales not an equal number of points matching the number of days in nearly all case. So the above is telling us for the first 3 days, no business value was delivered. Day 4 shows some value has been ‘Done’ as does day 6 and days 7,8,9 and 10. In this particular example it looks like the team were not going to meet their goal on several occasions, which could be for a number of reasons which are not important for the purposes of this example. However overall the sprint goal was met and there were clear points of value delivered.
So now lets look at some Cumulative Flow Diagrams based on a typical scrum board which has columns Tasks, Dev, QA and Done. The tasks are small units of work extracted from a story and do not have to be sectioned by skills. An example could be writing a test for instance.
CFD1 : Example workflow using cumulative flow
Unlike the typical burndown chart, CFD’s look at the movement of tasks, which are sometimes used as ‘burnup’ charts. This particular example is telling us more than just work completed. It’s clear that there is more development work than QA at the half of the sprint and vice versa the second half of the sprint. This is supported as the last 2 days of the sprint see much more QA than dev work. Without the context of the actual team applying this, the results are non-conclusive. However there are indicators here that a mini-waterfall is developing which has more development at the beginning of the sprint and more testing at the end. Even if the team is cross-functional and testing tasks are being tackled by everyone, the workflow itself could be suggesting that user stories are being tackled in bulk and not in priority order. This could be be a sign that two many stories are being tackled at once early on in the sprint which puts the sprint at risk.
CFD2 : Example workflow using cumulative flow
In contrast to CFD1, CFD2 shows a clear and levelled workflow. This is where there is a pretty consistent amount of work in progress through each story being tackled.
CFD3 : Example workflow using cumulative flow
CFD3 above shows a rather different pattern. This was actually taken from a team I worked with and clearly identifies there were some issues during the sprint, albeit the sprint goal was met. The key issue that was highlighted here was that when trying to test a story, the team discovered many more tasks as the nature of the testing was underestimated. This was swarmed on by the team, hence you will notice there was little in ‘Dev’ on day 5 as the whole team were working together on tests. Also the work in progress was exceeded distorting the accuracy somewhat.
Looking at all of the above CFD’s you’ll notice that a greater number of tasks gets ‘Done’ than was originally stated in the remaining ‘Tasks’ value. This is due to the path of discovery. Naturally as a team gets closer to implementing the problem, more knowledge emerges which sometime identified more work (highlighting why up front planning is flawed even on work in progress). Anther reason is that sometimes tasks can be split it to optimise workflow when getting closer to the problem.
Overall though I hope that it’s made visible above that CFD’s can support sprint workflow. These are not competing with a burndown based on stories, they are used to compliment workflow knowledge. The sprint burndown is a true reflection of delivered value where as CFD’s are more granular looking at a level below. You could have a nice diagonal line of progress on a CFD, but that could be flatlined on the burndown. Therefore the CFD’s does not replace a burndown. Applied as a workflow reflection, the CFD can be a useful learning aid to help teams. The patterns are not limited to the examples above and the same pattern may have many different reasons behind it which will need reflection with the team involved.