Burndown and Velocity explained
A Burndown chart shows the team’s progress toward completing all committed to pieces of work (GitHub Issues), that are estimated (using story points) within a single sprint (GitHub Milestones)—a set, timeframe that is not meant to change once started.
The chart starts in the top right, with the total number of story point the team has agreed to try deliver. It tracks, on a day-to-day basis, how many of those points have been completed/closed. This is represented by "step downs" when a dot and line are created, making a move towards the bottom-right of the chart, towards 0. The Burndown will also show a list of any in-completed Issues, meaning, any Issue that is closed outside the end date of the Sprint.
Velocity is how the team is able to measure the amount of work they have completed in a typical time frame, or over a longer timeframe. Velocity is measured historically, from one sprint to the next.
By tracking Velocity over a historical period, in ZenHub this is over the last 7 closed sprints, the team can build up a reliable and predictable metric of how many story points they can commit to within a sprint (story point average) relative to the cadence of commitments they're making.
Using Velocity to inform sprint planning
When planning for sprints, it's important to leverage the Velocity and and Burndown report together.
The Velocity chart will give you insights into how much you should be planning for in the upcoming sprint. Showing an average from the last 7 closed Milestones, you're able to understand what was actually delivered, not just what you were hoping to achieve.
By taking an average, the Velocity chart adjusts for swings in your sprints related to interruptions, resource constraints, holidays, or other things impacting how much work was taken on and completed. If you just look to the last sprint using the Burndown, you'll get a more immediate picture of what was just completed, but it's not as insightful as equalizing that over the more historical period.
Velocity is a tool for estimation, not a KPI
ZenHub supports complexity (story point) estimation, focusing on the delivery of value, not the time it took to complete something. Most people can relate to time easier, but it's important to not equate Velocity to a key performance indicator metric, but rather a trend line that can be used to help the team become more predictable.
Teams may find themselves favoring increasing the amount of work taken on per-sprint when they see the average velocity line, but you should only do that when there's more resources or team members available to you. When you "balance" the commitment you make in a sprint, and actually achieve the work within your sprint, you've found the balance between what you commit to and achieve.
This does not immediately mean you should take on more, as it's not a performance metric, but rather, a tool to help you become predictable with completing commitments in a time-boxed effort. In fact, a velocity chart that shows a constant increase (or decrease) might mean there's a hiccup in your process, and the team should reflect on what's causing the change (if it's not a resource change).
The point of velocity tracking is to improve the team’s ability to estimate how much work they can get done consistently and reliably.
When monitoring your sprint with the Burndown Chart beware of scope creep
When making commitments in a sprint, otherwise known as a sprint backlog, these commitments should be respected by everyone. Sprint disruptions do happen, and we share more on tips to best manage this process in ZenHub here, but if they happen continuously without an eye towards improvement, this is scope creep and bad planning. By making commitments, the team is able to be predictable.
Without proper tracking in the Burndown, on the Issues themselves, when changes do happen and scope creep occurs, it's difficult to understand how much of your Burndown is pre-committed to work, versus that that pops up mid-Sprint.
Velocity is used to inform commitments around amount of work taken on
Before kicking off any sprint, review your team's average Velocity line. Have this number in mind as you assign estimated Issues to your sprint. This doesn't necessarily mean the team shouldn't take on more or less, you should also discuss limitations and resources, but, the two should be aligned. It's all about predictability!
Once a sprint kicks off, the team's focus turns to the Burndown chart, which measures over time, how work is closing within your committed to timeframe.
