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.
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.
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.
To create a Burndown chart you first need to assign a start 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 left of the chart to confirm the day you started your sprint.
With a start and end date selected, estimated Issues with estimates that are added to the Milestone will begin to appear on the Chart. If you haven't yet added estimated Issues to a Milestone, or estimated the Issues within the Milestone, you'll see an empty state.
Head back to the Boards tab and filter by your current Milestone to begin estimating Issues within your sprint.
You can use the multi-select functionality on the Board to assign estimation to Issues from one central view.
When an Issue is closed, a new data point will appear.
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 on the Board.
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.