Quantitative Sprint Metrics

Teams use Sprint Metrics to evaluate progress within a Sprint, plan for future Sprint(s), and provide data for continuous improvement. There are many different metrics and data points that provide a holistic view of an Agile team’s progress, performance, and culture. The metrics in this article are used to help the team plan, forecast, and quantify their work.

Burndown Chart

Burndown Chart

The Burndown Chart, seen above, is a measurement at a specific point in time to determine the amount of work left versus time remaining. Teams use this metric to predict when work will be completed. Moreover, it is a great visual for the client, as it clearly shows progress. Burndown Charts can be created and used at the Sprint or Release level, and they use hours or story points as the work effort measurement. Within a Sprint, an Agile team will use a burndown chart to track the hours remaining for tasks versus hours available in the Sprint.

Burndown Charts include the following elements:

  • Ideal Line: A straight line starting with the total estimated hours or story points. It is an indication of the expected burndown rate, which is determined by using a mathematical formula or team Velocity. For example, a team of 5 may estimate that they will work 6 hours per day on the project. If they work in 2-week Sprints, then the starting line would begin at 300 hours. The ideal line would burndown at a rate of 30 hours per day.
  • Hours: The Y-axis in the burndown chart contains the hours or story points.
  • Time Remaining: The X-axis in the burndown chart reflects the Sprint days or the period of time that the burndown measures.
  • Progress Line: The progress line may vary depending on the team’s progress toward completion. There are various methods of calculating the progress line, including subtracting the actual hours worked or hours remaining for a specific task. If a team is completing tasks ahead of schedule, then the progress line will dip below the ideal line. In the same manner, if a team is behind schedule or new scope is added during the Sprint, then the progress line will display above the ideal line.

If a team consistently dips below the ideal line, this may be an indicator that the team has overestimated the work in the Sprint or some work is removed during the Sprint. If the progress line is above the ideal line, this may indicate that the team is facing an impediment that is preventing work from moving forward, work has been added to the Sprint which increased the Sprint scope, or the team has underestimated the work effort.

The burndown chart is best used when the team reviews it daily. This allows the team to proactively work to resolve impediments, mitigate risk, or pull in new work, depending on the progress line. Reviewing the burndown charts over a period of time will also allow the team to inspect and adapt their processes. Agile preaches transparency; there are significant benefits to visually viewing how a team performs daily. Additionally, the burndown chart depicts how the ‘team’ is doing, not how an ‘individual’ is doing. This promotes the team mentality: they fail as a team and succeed as a team.

Velocity Chart

Velocity Chart

Velocity is a tool that uses work completed in a given interval to assist in planning team capacity. Scrum Inc. recommends using the average of the last three Sprints to determine a team’s Velocity (Scrum, Inc.). Velocity is used to assist teams in determining how many story points they should plan for in a given Sprint. Using the team’s actual capacity and past performance, the team will determine how much work they believe they can complete in a Sprint.

The Velocity Chart includes the following elements:

  • Story Points: The accepted story points for each Sprint are used to create the average Velocity. Some Velocity charts include the story points that were not accepted, but they are not used in calculating the average Velocity. Including all the points provides transparency into the work that was committed versus the work that was completed.
  • Average Velocity: The average Velocity may vary depending on the work that the team is delivering in each Sprint. If a team is doing work they do not estimate, such as code refactoring, the average Velocity will drop. However, it is most beneficial to the team to estimate all work, including code refactoring.

Cumulative Flow Diagram

Cumulative Flow Diagram

Cumulative Flow Diagrams (CFD) provide visibility into the status of the work items for a period of time. It may be used to forecast delivery, provide visibility into cycle time, and identify bottlenecks. The bottom layer of the diagram represents the accepted work over a period of time. The top boundary of this layer also represents the burnup chart, which tracks the work progress toward completion.

The CFD helps to see if value is being delivered and how long it takes to deliver that value. The amount of time from when a work item is in progress to when it is completed is the cycle time. A longer cycle time may indicate that the team has too many items in progress or needs to split the work into smaller chunks, as long as they still deliver value. Work that is backing up in one state is also visible on the CFD, indicated by widening areas on the diagram. The widened area could be an indicator that many too items are in progress, impediments are preventing work from being finished, or the next stage is not able to absorb the work.

While the metrics in this article can be described as quantitative, it is equally important to measure the quality of the work that is completed by Agile teams. Capturing defect trends, escaped defects, test coverage, and technical debt help to identify the quality of the delivered products. In addition to measuring the team’s progress toward delivering high quality valuable products, the team’s maturity and morale should be captured. This can be done through Agile assessments and surveys to gauge the team’s well-being.

The quantitative metrics described in this article should be used to drive conversation and, hopefully, continuous improvement. They should not be used to compare teams or determine if one team is better than another. Teams should use these metrics in their Agile ceremonies and throughout their Sprints to inspect and adapt their practices to deliver value to their customers.


"Velocity." Scrum Inc. N.p., n.d. Web. 09 Dec. 2016.