Back to Blogs

Is that Sprint Burndown really worth it?

  • Publish Date: Posted over 9 years ago
  • Author: Tony Shawver

Is that Sprint Burndown really worth it?

Those who learn Scrum know that there are three basic artifacts where every Scrum team starts:

  • the Product Backlog

  • the Sprint Backlog

  • the Sprint Burndown Chart 

The business-driven, prioritized Product Backlog is a key differentiator from other process frameworks as it creates a “living” set of features that can evolve with the product, company, and customers to focus on the right business value. The narrowly focused Sprint Backlog is another key artifact that provides a Just-in-Time approach to refining and committing to a small set of the highest business value. But the third artifact, the Sprint Burndown chart, is what we will examine today and answer the question, “Is it really worth it?”

The Initial Value

A Sprint Burndown is one of the key artifacts in Scrum. It measures the remaining work (in hours) to meet the sprint goal. Plotting and updating this daily creates a nice, linear depiction of how the team is (or is not) progressing towards their goal. This artifact is especially helpful to new teams by giving them:

  • Transparency across the team and to any interested stakeholders

  • Helps the team refine its accuracy of abstract estimation by seeing actuals daily

  • A daily, easily read, progress-to-date on the current sprint goal

Sounds good so far, so what’s this about “Is it worth it?”

The Creation Process

Now let’s analyze how a Sprint Burndown is created. The Sprint Burndown is an output of the Sprint planning process which involves the following:

  • The Product Owner (PO) reviews the (groomed) candidate items with the team and covers “the what” conversation.

  • The team discusses the details with the PO, asks questions, and helps refine the story and drive out additional details and acceptance criteria.

  • The team goes away and discusses “the how”, talks through design approaches, breaks down the stories into tasks, and estimates each task.

  • The team then adds up all of the tasks and validates that the entire Sprint Backlog can be completed.

  • The team commits to the Sprint Backlog.

On average, the first two steps of this process take about one-half of the total Sprint planning duration, and the last three steps take the other half. For many teams, this equates to four team-hours for each half, or eight team-hours total. 

The Maturity Level

Experienced teams become much better at relative estimation. This is largely due to three main factors:

  • Product Architecture – Components, toolsets, & design patterns have been established and are stable, reducing risk and uncertainty.

  • Domain Knowledge – The team becomes steeped in the product domain and can relate to the content of user stories more quickly.

  • Relative Estimation Experience – Through experience, the team becomes much better at consistently assessing the size of a user story.

The Change: Discuss, Estimate, and Commit Without Tasking

As a result of the items above, Scrum teams can accomplish items 1, 2, & 5 (“the what” discussion, the story refinement, and the sprint commitment) of Sprint planning without the need for items 3 & 4 (“the how” discussion, tasking, and task estimation). Note that these items still need to be done, but can be done in more of a Just-In-Time manner. The one obvious loss is that without tasking and task estimates, you have no data to create a Sprint Burndown Chart. But let’s look at the pros of this approach:

  • Time Savings – This can save tremendous time by not spending team-hours on discussion, tasking, estimates, design. During the sprint, 2-3 team members can break down “the how”, and the remaining team members can be working on other items.

  • Throughput – The time saved translates into code-written & features-delivered, which is the primary metric of a Scrum team.

  • Re-hashing – This prevents re-hashing the same conversation because it happened over a week ago.

The Risks

Moving to this approach is not without risk, but I have found it to be manageable. The two risks I see most often are:

  • How do you tell Sprint progress? – The team can use a Story Board to see which stories are in what states of completion. While this is less accurate and more lagging than a Sprint Burndown, it still gives the entire team an approximate level of progress towards the goal. The Story Board is more accurate if the team is Scrumming (many people on fewer stories).

  • The entire team doesn’t participate in design, so architecture can diverge! – Yes, this can occur.  However, this approach doesn’t preclude full participation in the task breakdown and it promotes more collective ownership of the architecture.

In summary, the Sprint Burndown is a meaningful artifact for Scrum teams. For many teams, this artifact continues to be useful for adding transparency, refining estimation, and tracking progress. However, for mature teams, it sometimes makes sense to move away from the Sprint Burndown Chart. Ultimately, we’re practicing Agile to get working software into end-users hands more quickly, so the additional throughput is often worth the risk. 

Learn about our Agile Solutions

​