Scrum Artifacts: Velocity and Burndown Charts

The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.

Velocity Chart

Velocity is how a scrum team measures the amount of work they can complete in a typical sprint. Velocity is measured historically, from one sprint to the next. By tracking the number of story points the team can complete according to their own definition of done, they can build up a reliable and predictable sense of how long it will take them to complete new stories based on their relative point value.

Keeping track of the velocity is the responsibility of the scrum master. At the end of each sprint demo, the scrum master should calculate the number of points that were estimated for the stories that were accepted as done during that sprint. This number should be added as a data point on the velocity chart for that sprint.

Velocity charts tend to start out jumping around from very high numbers to very low numbers, as the team learns how much work they can do in a sprint, and how to estimate stories. The longer a team works together, the better they get at estimating stories consistently relative to each other. That skill leads to a better sense of how many stories, and how many points, the team can accomplish in a single sprint.

Over time, if the composition of the team stays consistent, a velocity chart that started off very erratic will start to find itself averaging toward a consistent value. Unlike many charts in a business environment, the point of the velocity chart isn’t to see a constant increase, but rather to see the values converging around a consistent horizontal line. That line represents the amount of work the team can realistically and sustainably accomplish in a single sprint.

Burndown Chart

A burndown chart shows the team’s progress toward completing all of the points they agreed to complete within a single sprint. This chart starts with the total number of points the team has taken on for the sprint, and tracks on a day-to-day basis how many of those points have been completed and are ready for the sprint demo.

The burndown chart is usually maintained by the scrum master, and may be updated on a daily basis, perhaps after the daily stand up, or on a continuous basis if it’s generated automatically by the tools the team is using to maintain the scrum board. The primary audience for a burndown chart is the team itself, although there may be data points on a burndown chart that could be relevant to people outside the scrum team.

A typical burndown chart starts with a straight diagonal line from the top left to the bottom right, showing an “ideal” burndown rate for the sprint. In practice, the point is not to match that ideal, but rather to keep in mind how much of the sprint is left at any point in time, and how much effort the team expects to be able to put toward the development of the product on any particular day of the sprint.

Lines or columns on the burndown chart may be used to represent the number of points of effort actually remaining in the sprint from day-to-day, starting with the number of points the team has committed to at the sprint planning. As work is completed, these columns should become shorter until they reach zero.

Some teams also choose to track the daily work completed, either in story points or in individual tasks toward completing stories. This can be done with a line or stacked columns, tracking these daily metrics against the burndown chart so they can be viewed in context.

There are very few legitimate reasons for a column to be taller on one day than it was on the previous day. If a bug is discovered before the end of the sprint, and a story that was marked as done or ready to demo needs to be worked on again, columns may increase in size from one day to the next. New stories introduced after the sprint has started may also cause one day’s column to be higher than the previous day’s. A pattern of rising columns on a burndown chart may indicate that the scope of the work is exceeding the originally agreed sprint backlog, which is definitely an anti-pattern in scrum.