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 
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:
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 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.
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.
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.
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.
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.
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.
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.
 A description of Burndown graphs from ControlChaos.com can be found here.