3 agile burndown reports and how to use them

Agile practices, to the uninitiated and underinformed, can sometimes appear as ad hoc software development and project management methodologies. The truth is far different.

One of the 12 principles of agile software states, “The best architectures, requirements, and design emerge from self-organizing teams,” but most organizations that apply agile practices, including scrum and Kanban, enforce some significant process rigors and rituals. For example, many organizations implement agile planning practices including story point estimation, architecture standards, and release management disciplines to improve the business impact, quality, and reliability of application releases.

Most teams elect to use an agile tool such as Jira Software or Azure DevOps to manage the backlogs, sprints, and collaboration between agile teams. The primary purpose of these tools is to centrally manage the requirements, sprint status, workflow, and collaboration across agile team members and multiple agile teams. However, the more rigor organizations put into using these tools, the more these tools can aid leaders and teams identify issues, report to stakeholders on status, and improve their execution.

One of the most common out-of-the-box reports is the burndown report. Since agile practices enable product owners to reprioritize the backlog based on customer feedback, traditional reports like Gantt charts fail to capture the fluid nature of agile execution. Fundamental to the burndown chart is that it accounts for completed work, new work added to the scope, and other scope changes. The burndown chart can provide a quick picture of how teams are marching toward their goals.

Reading a basic sprint burndown chart

Burndown charts usually have time across the x-axis and estimates on the y-axis. Many teams estimate in story points, but many agile tools can chart burndowns by the number of stories or estimates in hours. For this article, I’ll assume story points are being used.

The sprint burndown report plots the number of story points that are in scope for the time interval. As the team completes stories, the chart shows how they are “burning down” the list of stories and other types of work (issues in Jira, work item types in Azure DevOps) until the work is completed or the sprint ends. When teams complete the work committed to the sprint, the plotted line intersects the x-axis, indicating everything is done.

The sprint burndown is the easiest to conceptualize. On the first day of the sprint, the team commits to some stories and the total number of story points. If you review the burndown chart on that day, you should see a single point on the y-axis representing the number of points the team committed to on the sprint’s day zero.

As stories are marked done, the sprint burndown shows the remaining number of points to complete.

How is a sprint burndown used in practice? A healthy burndown shows a linear and ideally exponential curve down to zero. If the curve has a flat slope in the early part of a sprint, it may indicate blocks or a lot of work in progress and that the sprint may be at risk. A flat or slowly sloping burndown can be very problematic if much testing is performed on code-complete stories and if the testing work cannot begin until the last few days of the sprint.  

A rapidly descending sprint burndown is generally a good thing, but it may indicate that the team is undercommitting or has only elected to take on smaller stories in the sprint.

Epic burndowns track progress against business and technical drivers

Sprint burndowns are highly useful for tracking short-term execution and help teams successfully meet sprint commitments. To better track progress against longer-term goals, epic and release burndowns provide the needed visibility.

Epic burndowns work best when teams define several long-running efforts, such as implementing major end-user capabilities, technical debt strategies, performance improvements, or process evolutions. To take advantage of epic burndowns, the backlog should have:

• Between five and 15 epics that will last at least several months and take six or more sprints to complete.
• Features, stories, and story stubs that roll up underneath the epic and represent a high-level plan to execute on the epic.
• High-level estimates, ideally in story points for each story or story stub that rolls up under the epics.

Once these are in place, the epic burndown charts the changes to this plan. Its x-axis represents sprints, and the y-axis represents the total estimate of stories and story stubs assigned to the epic. In Jira Software’s epic burndown chart, you see a bar graph with one color representing stories completed in the sprint and a second that shows the story points added. Story points increase when new stories or story stubs are added to the epic or when estimates change.

There are several ways to use the epic burndown chart:

• It illustrates the velocity of completing features and stories against the plan. When plans are accurate and team velocity consistent, it can provide an indicator when the epic’s work is completed.
• Most agile plans are not complete, and teams add, change, and remove stories based on end-user feedback, the discovery of technical complexities, and to address technical debt introduced during the journey. The epic burndown then indicates how far off plan the epic is based on how much the backlog is growing versus being completed sprint by sprint.
• Epic burndowns also help benchmark efforts across multiple sprints and gauge how much planning and delivery work is done in one epic versus others.

Release burndowns inform teams whether releases will hit date and scope

Advanced teams who fully automate their delivery pipelines with continuous integration, continuous testing, and continuous delivery may not need release burndowns. Teams who deploy frequently should track what features and stories are tied to the release, but the release burndown isn’t very useful as it often tracks progress by sprint.

For other teams who follow release management practices and standardize on multisprint releases, the release burndown may be the product owner’s and team’s most important tool.

The release burndown is similar to the epic burndown except instead of tracking features, stories, and story stubs assigned to an epic, the release burndown shows what’s assigned to a release. The axis and the bars are then identical to epic burndowns.

Teams using release burndowns can thus track scope and timeline for a release. Teams who are on track will see a burndown slope down to the x-axis with a slope consistent with the team’s velocity. Releases that may be veering off track either have a smaller slope or depict more story points being added (when more scope is added to the release) than what’s being completed.

Jira Software helps you with these projections. Assuming the team has been working on the project for at least three sprints, Jira Software will compute an average team velocity and predict the ending sprint for a release based on this velocity.

The sprint, epic, and release burndowns give teams some easy-to-use tools to align on goals. When teams have a shared understanding of the scope, agree on priorities, plan several sprints ahead, and tag stories in their backlog appropriately, burndowns tell the story of whether planning and execution are aligned with goals. When they’re not, they are a data-driven tool that can fuel discussion on what adjustments may be needed.