The Sprint Burndown Chart
This is one in a series on Scrum Intro. The preceding post is here.
Now we come to the Burn Down charts.
You could start with either one, but let’s start with the Sprint Burndown chart.
We might first note that the Scrum Guide does not talk about a (Sprint) Burndown chart. There is a section in the Scrum Guide about “monitoring progress toward goals”, which mentions burn downs and burn ups.
What does it measure?
It gives our best guess, as of today, of the work remaining in the Sprint.
The way I recommend for beginning teams goes like this:
- In the Sprint Planning Meeting, we create the tasks needed to complete the stories. I recommend putting hours to those tasks. I recommend the tasks be small (typically 2-4 hours each). And that a person (or persons) be assigned to each task. (This was all discussed earlier.)
- Each day, the Implementers will get work done and learn. All of that information leads to revisions of the tasks. For example, some tasks can be replaced by other tasks. Tasks can be added. Tasks can be re-estimated. Tasks can be re-assigned to a different person, who gets to re-estimate the task.
- Just before the Daily Scrum, the Implementers make all the changes and put them “in the pot” (by which, I probably normally mean, into the Scrum tool). And then someone (maybe the SM) can then calculate the net effect and therefore how much work is remaining now.
- That enables setting the points shown above (as an example) and this the Sprint Burndown Chart.
The key thing is that this report is for the whole team.
The Team wins together or loses together.
So, the Team uses the Burn Down Chart to give them the information they need to self-organize, self-manage, and self-direct themselves to greater success (or less failure).
Some of the action by the Team is not discussed. It happens sub-consciously. Sometimes the SBD chart leads to a conversation, perhaps like the following:
Person 1: Yikes, we’re screwed.
Person2: Damn, well we have to do something. (And in that tone, from experience they know that means fix an impediment.)
Person3: I think [X] is the biggest thing to fix now.
Person4: I think the thing to do is [Y].
Person5: I’ll get started on that. Who can help me?
In this little conversation, you see the Team figuring out what to do.
The report is NOT primarily for others, but for the Team itself. They are the adults.
And we look for emergent leadership, people who rise in the occasion, and make it happen. email@example.com
The Sprint Burndown replies on the Team being as transparent, as honest, and as accurate as they can be about all the work remaining. And to everyone.
For example, if the Team decides that they will not complete a story, they might decide to stop working on it, and focus on stories that they still hope to complete. This is fine (or at least understandable that this will happen sometimes). First, they must be honest with all the people who care that that story is now “dead”. Then, they can take those related tasks out of the “work remaining”, and so, other things roughly as expected, that day we “burn down” more.
There is no point pretending that this day went well when it did not. Not point is pretending to make more progress than we really did. It does not help. It does not force us to make the changes we need to make it we “play pretend”. Equally, this can be challenging to managers, who too readily want to intervene if things do not go perfectly in one day. One day is not a problem. Even a “failed” (weak) Sprint is not a problem, so long as we eventually are successful.
Innovation work cannot be predicted with great accuracy and surprising things happen.
We recommend taking action and being willing to fail. We do not recommend forgoing all planning and all management; in fact, we recommend spending more (good and useful) time on those things. So that over time we end up being more successful. In large part by putting all our heads on the problem.
The next post in this series is [will be] here [TBD].