Karmængine

After I began maintaining a manual burndown chart for the sprint, I noticed that in reality the burndown chart was not telling us what we needed to know. It was based on completed tasks – and completed means coded and dev-tested.

Towards the end of almost every sprint, we were seeing that our burndown chart suddenly drops down as tasks are put through testing.

Due to this, we don’t really get an idea of where we are, in terms of development. An eight hour task could be coded but not tested, and that means eight hours still in the backlog. Spending twenty minutes testing it essentially ‘leaps’ the task from zero to completion. Not correct at all.

One solution is to report hours spent on all tasks, rather than just completed tasks. This might be even further from reality – essentially it would just show effort, which is generally not going to change from day-to-day and reporting it doesn’t show anybody anything.

This was causing me to have a minor meltdown, and thus this rather colourful chart evolved in my Excel spreadsheet:

The sprint meltdown chart.

Forgive me for the lack of labels here. Y-axis is number of hours (points) remaining in the sprint. X-axis is the nth day of the sprint.

The meltdown chart is always displayed as an ‘X’, with expected effort starting at zero and moving up to the planned hours limit, and expected burndown moving in the opposite direction.

Additionally, there is a central ‘window’ in the chart, and using this window I can spot mid-sprint what the outcome of the sprint will be if we maintain current progress.

There are four sections of the window, and briefly, if the real effort and burndown intersect in pane:

• 1. Effort needs to be reevaluated. Developers are sprinting and can probably cool off a bit, depending on whether burn is above or below average. If above, then tasks estimations are askew. In this case I would spend time to reevaluate with the team. If burn is below average, the sprint might have room for additional tasks. I would ask the developers if they would accept extra work added mid-sprint. Keep in mind that doing this might break the sprint later on.
• 2. Sprint is in serious trouble. If actual effort is below expected effort, it’s time to take the cane to the developers. In reality this can take the form of discussing the problems after a stand-up meeting, or scheduling a brief meeting. It’s likely the developers will state that they incorrectly estimated the tasks, and will complain that external factors are changing the scope. It could be time to alter the backlog, removing items if necessary.
• 3. Sprint estimated poorly, or horrible code quality. If the burn is in this window pane, then the second half of the sprint will be a walk in the park. You can decide if you want developers to stroll or pick up additional tasks. It might be worth paying closer attention to the quality of code – unless estimations were completely off, one or more developers could be writing rubbish code. I would spend time investigating the overall quality of the work done on the tasks.
• 4. Increase effort, depending on the burn, if it is above expected. If it’s below, effort can remain the same. Sprint is more or less on target.

These points depend mainly on how close the intersection is to the center of the chart. The closer to the center, the less attention you as a product owner need to pay.

In the image example, you can see our intersection landed in pane 2. From there, we turned up the effort of the developers, pumped them full of coffee, and managed to drag the sprint back on target.

I have no reservations when it comes to encouraging developers to work harder, but I see such effort boosts in terms of karma. More coffee mid sprint can more-or-less be translated into more beer at the end of it.