Burndown Charts are an essential Agile project management tool. These simple, visual representations 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 make it easy to see when the schedule is in jeopardy, giving the team the opportunity to intervene and head off problems early.
With ZenHub, Burndown Charts are automatically generated for all backlog items that have been estimated and associated with a Milestone. This automation eliminates the burden associated with maintaining burndown data manually. Accurate and up to date Burndown Charts for in-progress and recently closed sprints are always just a few clicks away.
The Anatomy of a Burndown Chart
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 is gone. Accordingly, a Burndown Chart begins with a sprint’s worth of work (usually expressed as story points) and progresses downward to zero.
Pictured above is a ZenHub Burndown Chart. 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 showing time in days.
- An ideal line which 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 which 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.
Metrics Agile Style
For those new to Agile, the simplicity of the Burndown Chart can mask its value. As with other elements of the approach, Agile project management metrics reflect certain core principals that distinguish them from the types of measurement we might see in classic software development models. Some of the primary drivers of Agile metrics are:
- Time-boxing: Agile development looks to maximize the work delivered within a specific period of time known as a time-box. 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.
- Focus on Team: 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, easy to understand the view of the current sprint, Burndown Charts may well be the perfect Agile tool to give the team the information it needs to quickly check progress and get back to work. Many teams include a review of the Burndown Chart as part of a daily standup. Burndown Charts are also often used as information radiators, an Agile term for visual tools that are posted in the team work area for everyone to see.
Digging Deeper – Analyzing Workflow
Burndown charts can tell you much more than whether a sprint is on schedule. 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 consistently underestimating story points. A good place to start addressing this type of problem would be a review of recent Velocity Charts for historical perspective on the team’s estimation and ability to burndown backlog.
- 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 or similar unavoidable sprint disruption, or it might be good old-fashioned scope creep. Although flexibility in the face of changing requirements is a main ingredient of Agile success, scope creep can still wreak havoc on the schedule. When possible, product owners should be encouraged to avoid adding new work to an in-progress sprint.
- Plateau – When things are going well and then progress suddenly stops, something fundamental has gone wrong with the project or team. 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, or the plateau could indicate a deeper problem with staffing or workflow management. Either way, plateaus are never a good sign and need to be investigated immediately.
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, 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. We can, and should, use the team’s velocity when planning sprints and deciding how many story points to add to a Milestone.
Burndown Charts and ZenHub
Burndown Charts in ZenHub are integrated directly with your GitHub Milestones.
There are a few prerequisites for generating Burndown Charts. 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.
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, you can change the definition of a complete task to better reflect your team’s workflow. For example, many teams choose to consider tasks that have moved into testing as complete.
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.
Incorporating Burndown Charts into your daily standups and other project management routines can really help improve performance and smooth out some of the bumps in the development cycle.
To learn more about creating 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.