At the start of every Sprint, a Scrum team commits to a certain amount of work represented by points using the Fibonacci sequence (1, 2, 3, 5, 8, etc.). The Fibonacci sequence is a series of exponentially expanding numbers, with each number representing a value of twice as much work as the preceding number. For example, a 3-point story represents twice as much effort as a 2-point story.
Then, the team looks at each member’s availability and calculates how many points it can take on during the upcoming Sprint.
Finally, the Burndown Chart is created using the number of committed points on the y-axis and the number of days in the Sprint on the x-axis.
For example, if a team has committed to completing 40 points over a two-week Sprint, the Burndown Chart will look like this:
In theory, this shows what will happen if the Sprint goes EXACTLY according to plan.
New Scrum Masters may believe this is reality. Seasoned Scrum Masters know it’s an impossible scenario.
As the Sprint progresses, the team will draw another line that shows the actual progress throughout the Sprint. In a perfect Sprint, the two lines would be identical.
But have you ever participated in a perfect Sprint? If you raised your hand, please introduce me to your pet unicorn – because it simply doesn’t happen.
Instead, especially with a newer or less-mature Agile team, we sometimes end up with one of the following scenarios.
Scenario 1: The Cliff
- The Scrum Master needs to work with the team to ensure their issues are updated daily.
- Did the team members not truly understand the Stories before committing to them, causing them to gather/clarify requirements during the Sprint?
- Is there a bottleneck in Code Review that is delaying the closing of issues?
- Did the Product Owner change the Story requirements after the Sprint began?
- Are team members taking on too many Stories at once and not completing them until the end of the Sprint?
- Was the team waiting on information and then had to ‘sprint’ to finish?
- During planning, ensure the Product Owner and the appropriate team members feel the Stories are fully understood and ready for development.
- Check-in during Daily Standup that team members complete stories before picking up new ones.
Scenario 2: The Bubbler
- Have a chat with your Product Owner – are they adding work to the Sprint without your knowledge? (Insider tip: this is a BIG no-no).
- Were stories not fully written or meeting the team’s Definition of Ready before the Sprint started?
- Have estimates increased during the Sprint? This could indicate a problem with the team’s planning/grooming/estimating process or a lack of technical review processes.
- Did the team take on additional work after beginning the Sprint, causing the line to ‘bubble’ back up?
- Did the team list some Stories as done but then pull them back to work on them?
- A lot of additional work was possibly added, creating stress for the team members.
- Ensure the Product Owner and the team have agreed on the work to be completed and that no additional work is added unless it’s an emergency.
- Ensure the Product Owner and the team agree on the definition of Done.
- Check-in with the team – how are they doing? Do they feel comfortable saying “no” to additional work?
Scenario 3: The Valley
- Did the team not take on enough story points?
- Is it a new(er) team? Maybe they are still learning how to estimate.
- Did the team forget to review capacity and velocity before starting the Sprint?
- Did the team estimate the Stories at a higher level of complexity than they truly were, causing the Stories to get done much earlier than expected?
- Were some of the Stories worked on in an earlier Sprint, giving the team a head start?
- It appears the team took on additional work on Day 7 to fill the Sprint but did not finish it.
- If the team is new(er), keep a close eye on their estimate for upcoming Sprints.
- This is a great opportunity to have a constructive conversation during the Retrospective to ensure pointing is being done accurately. Also, if pre-work was done in an earlier Sprint, discuss the benefits of documenting that effort.
- In this case, taking on extra work may be appropriate as long as the Product Owner maintains realistic expectations.
Scenario 4: The BCS (Best-Case Scenario)
- The team completed the points they committed to, on-time, with minimal deviation along the way.
- It does not appear that extra work was added to the Sprint.
- This looks great on the surface – was there an opportunity for a stretch goal as the team realizes they will meet their goals?
- Congratulate your team and have a great Review and Retrospective (and ask about that stretch goal)!
- Visit your local unicorn farm to inquire about availability 🙂
A Burndown Chart is an essential tool for any Agile team, providing valuable insights quickly and efficiently. There is no arguing with the Chart. It tells you exactly where the team is as it works through a Sprint.
The Burndown Chart is simple by design and provides easy access to the team’s progress for everyone, from the Developer to Scrum Master to Project Manager.
As straightforward as the Burndown Chart is, we must take a moment and ask the question – “Why?” In the earlier examples, we looked at:
- Why we might experience stagnation (“The Cliff”);
- Why it looks like we keep adding work to the Sprint (“The Bubbler”);
- Why we may see the work getting done sooner than expected (“The Valley”); and
- Why we may have just had “The Best-Case Scenario.”
By asking these questions and referring to the Burndown Chart during Sprint Review and Retrospective meetings, it becomes even more valuable as we plan for the next Sprint.
This post was published under the Agile Community of Experts. Communities of Experts are specialized groups at Modus Create that consolidate knowledge, document standards, reduce delivery times, and open up growth opportunities for team members. Learn more about the Modus Community of Experts here.