Burndown Charts – How Agile Teams Track Sprint Progress

Getting control of where work is going and knowing exactly how long tasks should take is a constant burden that managers of Agile software development projects face. But the more data you can gather and tweak on the spot, the better the chances are for you to take control of your and your team’s time.

Enter Burndown Charts.

What is a Burndown Chart?

Burndown Charts are simple, visual representations that provide a highly intuitive perspective, giving project managers and the entire team a snapshot of the team’s progress on the current sprint.

Burndown Charts make it easy to see when a sprint (a Milestone in GitHub and Zenhub) is on track to deliver all the promised features on schedule. They also show you when the schedule is in jeopardy, giving the team the opportunity to intervene and head off problems early.

What are the benefits of using Burndown Charts

The core advantage of digital Burndown Charts is that it’s simple to see what’s going on within your project in real-time. You can use these charts to directly analyze whether your current project progress is up to par with your initial estimates.

They require minimal effort to create and offer an immediate look at your team’s status. Additionally, they can be used to boost project transparency and keep all team members updated on the project’s current state.

The anatomy of Agile Burndown Charts

In Agile “burning down” the backlog simply means working through a group of outstanding tasks until there is no work left – think about burning down a candle until it’s gone.

Accordingly, a Burndown Chart begins with a sprint’s value of work (usually expressed as story points) and progresses downward to zero.

Pictured above is a Zenhub Burndown Chart example. The essential elements of the chart are:

• A vertical “y” axis showing the total estimated effort (story points) to complete the Milestone.
• A horizontal “x” axis shows time in days.
• An”ideal” line that shows how the project would progress if work were being completed at a steady clip. This line is shown as light grey and dashed.
• An “actual” line that shows the remaining story points as the team works through the Milestone. This line is purple and solid.

At the beginning of the sprint, both the actual and ideal lines show the total story points for all Issues and Pull Requests assigned to the Milestone.

As Issues are closed, the Burndown Chart automatically reflects the completed work. The variance between ideal and actual lets the team know how closely they are performing to plan. If the actual line is running underneath the ideal, then the team is ahead of schedule. If the actual line is running above the ideal, then the team is falling behind.

Agile Burndown Chart metrics

Agile project management metrics reflect certain core principles that distinguish them from the types of measurement. Some of the primary drivers of Agile metrics are:

• Time-boxing: Smaller time-boxes are generally considered to be the most effective, with teams typically pursuing sprints of one to three weeks.
• Delivering Functioning Software: Agile is focused on the frequent delivery of usable software features, rather than long development cycles with interim deliverables.
• Focusing on Teams: Agile metrics (as opposed to business metrics) are primarily intended to provide feedback to the development team members to help them track their progress, keep on schedule, and improve their approach.
• Keeping it Simple: Agile project management prizes simple, intuitive metrics. Agile recognizes that measurements and predictions can never be perfect and therefore seeks metrics that are easy to maintain and understand while being “good enough” to help the team be successful.
• Immediacy: Agile teams rely on frequent feedback. Metrics that provide a real-time or daily view are considered ideal.

With their no-nonsense, Burndown Charts may well be the perfect Agile tool to give the team the information it needs to check progress and get back to work. Many teams also include a review of the Burndown Chart as part of a daily standup.

Agile burndown patterns – Analyzing team workflows

Pictured below are just a few of the many patterns project managers look for when they want to dig deeper into their burndown data for insights into the root causes of schedule problems and valuable information the team can use to make process improvements.

• Underestimation – When the actual line steadily diverges from the ideal line, and the team falls increasingly far behind on the scheduled work, it’s a good indication that the schedule is too optimistic. Perhaps too many story points were included in the sprint or the team was underestimating story points.
• Scope Creep – When the actual line in a Burndown Chart starts moving in the wrong direction [i.e. the amount of work remaining in the sprint is growing] it is often a sign that new work is being injected mid-sprint. This new work might be an urgent bug fix, an unavoidable sprint disruption, or the old-fashioned scope creep.
• Plateau – A plateau in the burndown might be the result of a temporary setback such as a poorly defined user story or a key team member needing unscheduled time off. The plateau could also indicate what your blockers are or a deeper problem with staffing or workflow management.

Velocity and burndown – Better together

While burndown is a current measure of how much work is remaining in the sprint and can show how well the team is achieving the sprint goals, velocity is the Agile measure of historical performance that captures how quickly the team has been able to complete work in the recent past.

Zenhub Velocity Charts automatically capture the prior seven milestones and calculate the team’s average velocity over that period. A sample Zenhub Velocity Chart is shown below.

In the example chart above, we see that the team has closed five Milestones with a total of 102 story points. The calculated velocity of 20.4 tells us that the team could be reasonably expected to complete about 20.4 story points per sprint in the future.

Agile Burndown Charts and Zenhub

There are a few prerequisites for generating Burndown Charts in Zenhub. Milestones must have start and end dates. End dates are set when you create a Milestone in GitHub, but Milestone start dates are unique to Zenhub. Also, the Issues that are assigned to the Milestone must-have story point estimates.

Burndown Charts are found in the Zenhub Reports tab. They are automatically populated, moving the actual line closer to zero every time an Issue is closed. This automation eliminates the burden associated with maintaining burndown data manually.

Zenhub Burndown Charts are powerful out-of-the-box, but there are several customizations available to help you make sure they are optimized for your team and workflow.

One key customization is the ability to control what ZenHub counts as a burned task. By default, Burndown Charts show closed Issues and Pull Requests. Using the Burn Pipelines dropdown menu, change the definition of a complete task to reflect your team’s workflow.

Another powerful customization and one that showcases Zenhub’s capabilities to unify your GitHub view is the ability to create multi-repository Burndown Charts.

All that’s needed to create a multi-repository Burndown Chart is to connect the repositories you want to track in a Workspace and make sure the same Milestone, with the exact same name and end date, exists across those repositories.

Why estimates are needed to create the Burndown Chart

In Zenhub, Sprints are defined using GitHub Milestones. Each Milestone gets its own Burndown Chart.

To create a Burndown Chart, the Milestone needs:

• A start and end date
• Estimated Issues within it

Estimates provide information on how complex a piece of work will be to complete. By assigning a group of estimated Issues to a Milestone, you track your team’s throughput.

An intro to story points and estimates

Estimation helps make those unknowns easier to action and avoid next time. People are inherently bad at guessing how long it would take to complete a project without having a point of reference. It becomes much easier to provide an estimate if it gets compared with a project previously done.

By estimating work with story points, you create a shared understanding of how difficult a piece of work will be to finish. This allows individuals with different skills and experience levels to agree and understand how hard something will be to implement. This helps eliminate some uncertainty around how long complex projects will take.

Assign your first few estimates by assessing recently closed items and your top 3 backlog issues

Look at what’s coming up in your sprint backlog. Select your top 3 highest priority sprint backlog items. These Issues will have more details, making them better understood by the team.

By default, Zenhub uses a popular Scrum method of estimating, the Fibonacci sequence. This sequence starts at 1 and ends at 40. This is because estimation is done by using a scale that exponentially grows. The higher the number, the more risk, unknowns, and dependencies there are with the Issue.

The highest value estimate, 40, means that the Issue you’re looking at is simply too big to estimate and you need to break things down into smaller Issues. Whereas a 1 means that it’s a really easy task for anyone in the team to finish.

To define what a 1 means for your team compared to a high-risk Issue, set up a time with your team to look back at big chunks of work that you have recently completed.

• Choose one of the easiest Issues you’ve recently closed: assign this a story point of 1.
• Choose the most difficult Issue you’ve recently closed: assign this issue a 21.

Remember, the highest estimate value 40 should be reserved for Issues too undefined or unknown. Use this as a visual cue to the team that it shouldn’t move forward until there’s a discussion to break it into smaller Issues.

Next, look at your highest priority Backlog Issues and discuss as a team how easy/very difficult each Issue is compared to the two Issues you just assigned a 1 and 21. Use your next few sprints as a way to define what each value in your estimation scale means relative to the work your team does.

One of the key differences with estimating using story points, over tracking the number of hours something will take is that story points are relative to each other. This means you have to constantly talk about Issues relative to each other to get familiar with story points!

As a benchmark, here’s our framework for what the estimate values mean in relation to Issue complexity:

• Issues assigned 1 or 2 should be well understood and have zero risks associated with them.
• Issues assigned 3 or 5 are considered moderately complex, might have multiple ways to fix them or approach them, and might have some technical risk associated with them.
• Issues assigned 8 are seen as quite complex and should prompt further conversation from the team to figure out how they can break down these Issues into smaller, more manageable tasks.
• Issues assigned 21 should likely be an Epic, signaling this is project-level Issue.

Creating a Burndown Chart

After adding story points to Issues, the next step is to use GitHub Milestones to track what’s in progress and upcoming. GitHub Milestones create Zenhub Burndown Charts to help teams understand a few key insights:

• How much you’re committing to within a set duration of time
• The ideal speed at which the team should be completing work across that timeline
• And, how the team is actually completing work.

When comparing the actual speed of completion against the ideal timeline, teams get early indicators of how a group of work the team committed to is coming along.

How to read a Burndown Chart

Along the middle of the graph is a light-grey, dotted line. This line represents the speed at which you need to be closing or completing Issues to complete all Issues you’ve set out to achieve. You can be confident you’ll achieve your goal if your team’s completed work closely aligns to, or is below this diagonal timeline.

Purple dots will appear above or below the grey line as they get completed. Only Issues that are estimated will make the line drop to zero.

Unestimated Issues can be added to a Milestone, but they won’t count towards the Y axis. The Y axis is created by the sum of all story points assigned to Issues in the Milestone.

If you do not use Closed as ‘done’ you can use the Burn pipelines option on the top of the chart to set which pipelines represent work that your team views as ‘done’ in the Sprint.

To learn more about creating Scrum Burndown Charts in Zenhub and using them to track your progress see this handy guide Track Sprint Progress with Burndown Charts and download our free ebook: Better Software & Stronger Teams.