Seven common Sprint Burndown graph signatures

This first appeared on the ScrumAlliance.org website on October 30th. It is presented here in its original unedited form.

Burndown graphs are commonly used in Scrum projects to give the team an understanding of the amount of work remaining for the Sprint (or iteration). In Ken’s own words:

“As a team works together, it develop its own style of creating and maintaining the Sprint Backlog. It also demonstrates unique work patterns, some working consistently, some in bursts, some at the end of a Sprint. Some seek pressure, while others seek regularity. Across time, the backlog charts of each team develop predictable patterns. They stabilize as the team learns the technology, the business or product domain, and each other. These chart patterns are called Sprint signatures.” – ControlChaos.com [1]

Although burndown charts are very individual to the project team, I have noticed that some similar signatures recur project after project. The graphs that I’ve drawn are intended to show the general trend and are greatly stylized. Real graphs are more chaotic with datapoints both above and below the trend lines. Here’s an example of what a real burndown graph often looks like:

early-learner.png

This article is a collection of 7 burndown signatures that seem to be the most common and which I hope readers will recognize in their own projects.

The Fakey-Fakey
The Fakey-Fakey is characterised by a strong and regular descent towards completion. Most software is sufficiently complex that there needs to be some discovery along the way. Presenting regular and predictable progress in a complex and ever changing field is, at best disingenuous and at worst it presents a false impression on the state of the project. The Fakey-Fakey is often presented by teams that are operating in a very command and control environment where they are uncomfortable with being open and honest.

fakeyfakey.JPG

The Late-Learner
The Late-Learner has a learning hump (indicated by the blue shading) towards the very end of an iteration. The Late-Learner is common for new teams that are still trying communicate effectively, and are still coming to terms with the Scrum concept of creating software that is “Done” by the end of the iteration. In newly forming teams, the late hump is often due to a very late realization that testing is an important part of delivering demostrable software at the end of an iteration.

latelearner.JPG

The Middle-Learner
As the team starts to mature more emphasis is place on early discovery especially the early definition of what needs to be tested. This helps to move the bulk of the work into the middle of the sprint as shown below.

midlearner.JPG

The Early-Learner
Scrum teams that are perfoming will often have a sprint burndown graph with an early hump and then a gradual burndown. In this case the team has learnt the importance of early discovery usually by early definition of what needs to be tested. Once they have a more substantial defintion of what needs to be accomplished in the sprint, they work steadily to achieve it.

earlylearner.JPG

The Plateau
While teams are trying to find a balance between Early-Learner and Late-Learner they will often go through a phase where they initially make good progress but this progress is not carried through to the end of the sprint. The burndown signature will look something the Plateau.

theplateau.JPG

The Never-Never
Sometimes a team that is working well together will have an unexpected surprise at the end of the sprint. Perhaps the team sought clarificiation too late in the process, or perhaps the Product Owner wanted to change the scope of the sprint. A sudden increase in the amount of work outstanding very late in the Sprint (whether due to late discovery or scope change) will make it difficult for a team to be able to meet its commitments. These late changes need to be raised and resolved as part of the retrospective.

nevernever.JPG

The Scope Increase
This graph is characterised by a sudden increase in the estimated amount of work remaining. It’s usually a sign that the team did not fully appreciate the scope of work committed to during the sprint planning meeting. There are several approaches to dealing with very large scope increases. My prefered approach is to negotiate with the product owner, but in situations where there is a complete disconnect in understanding the team may want to consider terminating the sprint.

scopeincrease.JPG

Bookmark and Share

References
[1] A description of Burndown graphs from ControlChaos.com can be found here.

About these ads
Comments
7 Responses to “Seven common Sprint Burndown graph signatures”
  1. Nice! I’ve got another look at common burndown issues in http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf

    • Kane says:

      I really like your article, and I would encourage others to read it also. Good reading. I’ll be sure reference it in the future.

Trackbacks
Check out what others are saying...
  1. [...] useless. Perhaps that’s why I like Scrum so much–it only requires participants to estimate the hours of work remaining. Johanna Rothman wrote a short but important piece: Managing Product Development: There is No Such [...]

  2. [...] Burndown Chart is another subtle force against the transparency required for collaboration. As Kane Mar has written, a high-performing team can expect the Sprint Burndown to go up before it goes down because (in the [...]

  3. [...] Sidebar: Seven common Sprint Burndown graph signatures [...]

  4. [...] Burndown focada em mudanças na sprint. Há também um outro artigo muito interessante de Kane Mar, Seven common Sprint Burndown graph signatures, onde ele separa o Burndown em sete categorias apresentando as nuances desses diversos cenários. [...]



Follow

Get every new post delivered to your Inbox.

%d bloggers like this: