Velocity metrics and usage guidance

Azure DevOps Services | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Velocity metrics provide useful information to support the following team and product management activities:

  • Sprint planning
  • Forecasting future sprints and the backlog items that a team can complete
  • A guide for determining how well the team estimates and meets their planned commitments

Velocity chart types

You have a choice of Velocity charts: the in-context Velocity chart you access from a Backlogs page and the Velocity widget you add to a dashboard. With both these charts, you can quickly determine the following information:

  • Planned - calculated based on the amount of work assigned to the sprint prior to the start of the sprint. This count includes work that was moved to a different sprint after the start of the sprint, but doesn't include work that was added later after the sprint started.

    Tip

    To list the work items included in the count, click the velocity bar. A query results page will open with the list of work items included.

  • Completed - calculated based on the amount of work assigned to the sprint prior to the start of the sprint and completed prior to the sprint end date..
  • Completed Late - calculated based on the amount of work assigned to the sprint prior to the start of the sprint but was completed after the end of the sprint.
  • Incomplete - Amount of work not completed, calculated based on the amount of work assigned to the sprint prior to the start of the sprint and has not been set to completed.

You can configure each chart in the following ways:

The widget supports some additional configuration options. To configure or view Velocity charts, see Configure and view Velocity charts.

You have a choice of Velocity charts: the in-context Velocity chart you access from a Backlogs page and the Velocity widget you add to a dashboard. With the velocity widget, you can quickly determine the following information:

  • Planned velocity
  • Actual (completed) velocity
  • Work completed later than planned
  • Amount of work not completed

Both of these charts support visualizing team velocity for several sprints. The Velocity widget, however, supports the following configuration options:

  • Sum of Effort, Story Points, or Size fields or other supported numeric field assigned to backlog items.
  • Count of work items that appear on the backlog
  • Number of iterations
  • Advanced features.

The in-context Velocity charts are based on the sum of Effort, Story Points, or Size fields assigned to backlog items. These charts are similar to the one shown in the following image.

Web portal, Velocity chart showing seven sprints of in progress and completed work

To configure or view Velocity charts, see Configure and view Velocity charts.

For your team to gain the greatest utility from the velocity charts, follow these required and recommended tasks.

Required:

  • Define iteration paths (aka sprints) and configure team iterations Sprints should be of the same duration.
  • Define and estimate backlog items. If you work from your team's backlog, the items you create will automatically be assigned to the current sprint (Iteration) and to your team's default Area Path.
  • Update the status of backlog items once work starts and when completed. Only backlog items whose State maps to a metastate of In Progress or Done will show up on the velocity chart or velocity widget.

Recommended:

  • Define and size backlog items to minimize variability.
  • Determine how your team wants to treat bugs. If your team chooses to treat bugs like requirements, bugs will show up on the backlog and be counted within the Velocity chart and forecasting.
  • Set your team's area path. The forecast tool will forecast those items based on your team's default settings. These settings can specify to include items in area paths under the team's default or exclude them.
  • Don't create a hierarchy of backlog items and bugs. The Kanban board, sprint backlog, and task board only show the last node in a hierarchy, called the leaf node. For example, if you link items within a hierarchy that is four levels deep, only the items at the fourth level appear on the Kanban board, sprint backlog, and task board.
    Instead of nesting requirements, bugs, and tasks, we recommend that you maintain a flat list-only creating parent-child links one level deep between items. Use Features to group requirements or user stories. You can quickly map stories to features, which creates parent-child links in the background.
  • At the end of the sprint, update the status of those backlog items that the team has fully completed. Incomplete items should be moved back to the product backlog and considered in a future sprint planning meeting.

Minimize variability in your estimates

Estimates, by their nature, don't reflect reality. They represent a best guess by the team as to the effort required to complete an item, relative to the effort of other items on the backlog.

By minimizing the size variability of your backlog items, you help strengthen the team's ability to create more accurate estimates. Variability increases uncertainty. By minimizing the variability of your estimates, you increase the likelihood of more reliable velocity metrics and forecast results.

Velocity is not a KPI

While velocity provides a measure of a team's ability to deliver work, you shouldn't confuse it as a key performance indicator for the team.

Velocity simply provides an aid to determine team capacity. Nothing more, nothing less. Asking a team to increase their velocity, basically asks them to accomplish more with the same resources. This request will mostly likely lead to "Story points inflation" and lead to less desirable outcomes.

Other types of velocity charts

While the velocity chart provides a measure of Effort, Story Points, or Size that gets completed sprint-over-sprint, there may be other types of velocity that you may want to track. You can create similar charts by creating a work item query and chart the count of or sum of items.

For example, you can create a chart of the number of Product backlog items and bugs completed for the last several sprints. For examples on creating this type of chart, see Query by numeric fields.

Velocity count of backlog items and bugs

Next steps

Add other teams

If you work with several teams, and each team wants to work with their own backlog view, velocity chart, and forecast tool, you can add teams. Each team then gets access to their own set of Agile tools. Each Agile tool filters work items to only include those items assigned to area paths and iteration paths selected by the team.