It’s six Sprints after the “Overtime/Disastrous Release”, which set the team back by several months. During the current Sprint Planning, the Team committed to completing the following nine User Stories:
Julia and Rob – are personas used by the BookStore Team to keep them focused on the needs of real users. Julia is a Frequent Book Buyer and Rob is Rookie or First Time Book Buyer.
- As Julia I want to be able buy a $10 gift card so that I can thank a fantastic client. Limitation – not delivered just generated – Size: 5
- As Julia I want my newly purchased gift card sent by email to its recipient so they can use it quickly. – Size 3
- As Julia I want to be able to refill a gift card I previously purchased. – Size 2
- As Julia I want to be able to buy a gift card in denominations of $25, $50 and $100 so I can have choices in how much money I want to spend. – Size 2
- As Julia I want fancy graphics and text on my gift card to satisfy my inner diva. – Size 3
- As Rob I want to be able to use my new received Gift Card so that I enjoy another book without the pain of paying for it. – Size 3
- As Rob I want to be notified by email when I receive a Gift Card so I can use it quickly. – Size 2
- As Rob I want to see the remaining balance on my Gift Card so I know how much I have left to spend. – Size 1
- As Julia I want to be notified when the Gift Card I sent runs out of money so I can replenish it. – Size 3
The stories have estimates (sized 1, 2, 3, with one 5), are reasonably well split and initial acceptance criteria (not illustrated here to save space). Their total of 24 story points seems quite achievable based on the past few sprints velocity. In addition, they break the Stories down into tasks with a total of 323 estimated task hours.
Day by day during Daily Standup, they update the number of Estimated Task Hours of work they currently believe are remaining in the Sprint. This table shows their progress:
| Day | Stories in Progress | Stories Completed | Task Hrs Estimated Remaining |
| 1 | 4 | 0 | 300 |
| 2 | 4 | 0 | 265 |
| 3 | 5 | 1 | 235 |
| 4 | 5 | 1 | 178 |
| 5 | 5 | 1 | 153 |
| 6 | 5 | 2 | 116 |
| 7 | 5 | 2 | 101 |
| 8 | 5 | 4 | 60 |
Every day during the Sprint, Steve (the ScrumMaster) asks the team, “Are you still on track to hit our goal of nine stories?” At Day Eight, the team has approximately sixty hours of work left, four completed stories and five in progress. Steve asks his Daily Question, “Are we really going to make it?” All of a sudden, the answer is No. Steve asks, “Which Stories can we realistically complete?” The team pick two and immediately go and find Sue to tell her which three stories they’re dropping.
As they leave the Daily Scrum, Brad quips, “That’s really not so bad, is it?”
Analysis
Is it really that bad? Yes.
- If the team can’t regularly hit their commitment, the Product Owner and the Business as a whole will rapidly lose faith in them.
- When the team’s commitment in Sprint Planning doesn’t mean anything to them, then they won’t be focused or motivated to achieve their target.
- When the team miss the commitment on more than a few occasions, predictability goes right out the window.
How did this happen? Sprint Burndowns tracked estimated hours of work remaining to get people to focus on an ideal line (properly called a ‘rhumb’ line). They tend to focus on the rhumb line because that’s what they think management want. They also pay attention to it even when it isn’t drawn, because we assume the natural path to done follows that line. In reality, real Sprint work rarely fits that line.
In addition, tracking task hours tends to get people to focus on the delivery of tasks hours, instead of delivering value. Consider two Teams on Day Eight of a two week Sprint. Assume that they worked on the same Stories for the same Sprint. Team ‘B’ paid careful attention to Sprint Burndown and Team ‘A’ focused on delivering value.
| Team | A | B |
| Estimated Hours Work Remaining | 100 | 60 |
| Completed Stories | 6 | 4 |
| In Progress | 2 | 5 |
| Not Started | 1 | 0 |
Clearly Team ‘A’ is better off even though they have more task hours remaining, since they’ve focused on getting their Stories to complete. With Team ‘B’, even though their Burndown will look closer to the ideal line, we’ve no idea what will really get done – very likely not all of them, since the team will bottleneck on Testing. If Team ‘A’ focus on delivering, they will definitely get at least one of the In Progress Stories to done, and perhaps two. They definitely won’t get the last one done, but the Product Owner won’t be surprised.
Tricks that help
- Measure your Sprint Burndown in Number of Stories or Story Points. Only burndown when a Story is completed.
- Limit WIP (Work In Progress) – this forces the team to finish Stories, collaborate, and share knowledge. Rally showed in a recent study that reduced WIP correlates with getting more Stories to Done and fewer Defects.
- Choose a clear and effective Sprint Goal – in this case a good Sprint Goal might have been: “By the end of the Sprint the Basic Gift Card should be available”. The Sprint Goal allows team members to ensure that their work is driving towards a greater goal. It helps maintain focus more effectively than a random grab bag of Stories. And if something needs to be dropped, it gives greater clarity around that choice.
Some of the most effective Teams I’ve seen dispense with Sprint Burndowns altogether and just focus on the flow of work across the Scrum Wall. They focus on getting the Stories themselves to completion and the tasks are just aids.
For those who prefer to use a Sprint Burndown consider – Sample Improved Sprint Burndown:
Just counting the number of Stories puts the emphasis on getting Stories to done. Even Story Size in Points can be distortive because it makes large items seem valuable making a cliff like burndown more likely. Just counting Stories puts the emphasis on the delivery of value.
If the team had this, they would have seen sooner that they weren’t going to get everything complete. They could have adjusted their approach to get some Stories done sooner.
Have you been burned by Sprint Burndowns?
Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
I definitely see the merit in this point of view; ultimately a team delivers value by finishing a story and the number of hours worked is only correlated to value rather than being a direct measure of it. On the other hand, inevitably the number of hours in a sprint far exceeds the number of story points – depending on team size this can even by a factor of 100 or more and therefore visualizing the burn-down in hours rather than story points gives a more granular view. I think the ideal would be to visualize both story points and hours overlain as the relationship between the two lines is in itself telling.
Lesile – thanks for the comment. I understand the desire for something more granular but these are empty calories. They feel good without delivering any value. A better approach would be to slice all User Stories to 1, 2 or 3 story points ensuring the team finish a story every couple of days.
we use both points and hrs. these are just two data points that give us an understanding of progress. maybe i’m missing something but not sure why it was caught so late in the sprint that they were not going to get the stories completed. good discussion for the retro on what to do better during the next sprint. i would key on the daily stand-ups.
DaBear – you can do both, if you have the time and energy. I **personally** have limited quantities so I only focus on the value delivered the stories.
The article was written mainly to highlight the danger of doing what the earliest Scrum books suggested – Sprint Burndown in hours.
All modern tools are an improvement.