Burndown Charts are often associated with Scrum, a development methodology known for incremental releases and a focus on customer requirements. As an agile workflow tool, they help teams meet deadlines more predictably by providing an early indicator of how a project is coming along.
Because they provide a visualization of complete and remaining work, they're also a user-friendly reporting tool for GitHub project management.
Just like kanban boards and Epics, Burndown Charts can help you visualize projects across repositories. In ZenHub, each Milestone (sprint) gets its own Burndown Chart.
Creating Burndown charts in GitHub using ZenHub
Burndown Charts are meant to track velocity during short sprints of work – and as such, they are integrated directly with your GitHub Milestones. You'll find your team's Burndown Charts in the Reports tab. To build your chart, you'll need to choose the Milestone start and end dates (find the edit link at the top of the chart.) After choosing a Milestone, all the Issues which have been estimated will be shown.
To create a Burndown chart you first need to assign a start and end date for your sprint. The due date was already set when you create the Milestone, but the start date of a Milestone is unique to reporting in ZenHub.
Select Edit on the top right of the chart, or click Change to select dates.
With a start and end date selected, you need to ensure there are estimated Issues that are added to the Milestone. If you haven't yet added estimated Issues to a Milestone, or estimated the Issues within the Milestone, you'll see an empty state. New to estimation and need best practices? Check out our guide to estimating for the first time here.
Adding Issues to your Sprint (GitHub Milestone) en-bulk
Head back to the Boards tab to organize the Sprint. You can use the multi-action to select multiple Issues to be added to the Sprint, or, estimated if you forgot to estimate an Issue but discussed it as a team.
The Burndown will auto-populate data points as Issues are closed
As you finish Issues assigned to the Sprint, a new data point will appear, "stepping down" in the chart.
Along the middle of the graph is a light-gray, dotted line—This line represents the speed at which you need to be closing or completing Issues within your sprint to complete all Issues you've set out to achieve in the sprint. You can be confident you’ll achieve your goal if your team’s completed work closely aligns to this diagonal timeline.
Defining what is "done" using burn pipelines
By default, Burndown Charts display closed Issues and Pull Requests as data points. You can also customize which pipeline triggers a “burned” task by using the Burn Pipelines dropdown menu. For example, if your development team considers a task complete when it reaches the “Ready for QA” pipeline, they can set that here for a more accurate picture of their priorities and progress.
Creating multi-repo Burndown charts
To create a multi-repository Burndown Chart, you'll need to start by connecting repos in a Workspace. In addition, you also have to make sure the same Milestone, with the exact same name and end date exists across all repos you'd like to track together.
Create the same Milestone across your connected repos using the multi-repo Milestone creator. Learn more here.
You'll then see the connected repositories listed at the top of the chart, and any merged Milestones will appear together as one.
Close out a sprint to complete the Burndown
Close the Milestone at the end of a sprint in the same section where you create the Milestone, under the Issues tab.
On the right of every open Milestone is an option to close. Once closed, you can still filter the Board and view all Issues that went into the Sprint; however, one of the key benefits of closing a sprint is that it provides additional reporting around your team's average velocity.
We encourage teams to close Milestones in the Web App when using cross-repo Milestones to ensure all connected Milestones are closed at once. Learn more here.