Measuring Team Velocity

What is Team Velocity?

Team Velocity is the average rate of how fast the team converts user stories from the product backlog to potentially releasable increment per Sprint. Strictly speaking, it should only account for Story Points that deliver value or functionality. However, in reality, Development Team performs activities that are not directly related to functionality but are essential to successfully building and maintaining the product. Development also incur technical debts that maybe intentional or unintentional.

In this article, we will consider also the “non-value” Product Backlog items in calculating for velocity. It is recommended that the Product Backlog items be classified into at least 3 categories:

  • Functionality, these are working functionality/feature/user story included in the product increment. This will include implemented functionality/feature changes.
  • Technical Debts, these are rework items or undone items that reduces velocity. Development effort is rendered to service the debt and when debts are accumulated, it makes it harder to implement changes later on.
  • Technical Investments, on the other hand, are activities that enable more efficient delivery of functionality in the later Sprints. Like monetary investments, it incurs costs at the beginning but will have compounding benefits when successfully utilized. Activities may include: setup of environment, continuous integration systems, architecture, and actionable improvements identified during the retrospect.

Why Measure Team Velocity?

Team Velocity can be used to make predictions. It is an input to Sprint Planning. It can answer the following questions:

  • When can the team deliver all the items in the backlog? or,
  • How many items can the team deliver at a certain time?

Team Velocity helps improve the team to get better and better. The team should identify ways on how to increase their velocity at least every retrospective.

Team Velocity Histogram

The Development Team should be able to gather metrics at least every Sprint Review to measure velocity and its surrounding factors. Here are the metrics that we gather relating to Velocity that can help in forecasting.


  • X – Axis: Sprints, sprints with values are already completed
  • Y – Axis: In unit of Points, these are relative estimates of each Product Backlog items completed
  • Z – Axis: In units of Hours


  • Forecast (Blue Line): This is the total number of story points estimated by the Development Team to be completed for the sprint. Increasing trend is GOOD.
  • Velocity (Red Line): Total points completed over the total number of sprints at the time of data collection. For example: Sprint 2 Velocity = (Sprint 1 + Sprint 2 Completed Points)/2 Sprints. Increasing trend is GOOD.
  • Capacity (Orange Dotted Line): Sum of available developer hours for the Sprint. The development team can use this information when forecasting. Sustainable/constant trend is GOOD.
  • Actual Hours (Light Blue Dotted Line): Total Actual rendered hours per sprint. This is to consider the rendered hours when making forecasts. It is possible that the velocity is high but the developers are not working on a sustainable pace of 7-8 hours per day. Sustainable/constant trend is GOOD.
  • Technical Debt (Orange Bar): Indicates how much effort is spent on servicing technical debts per sprint. Reducing trend is GOOD.
  • Functionality (Blue Bar): Indicates how much functionality is delivered per sprint. Increasing trend is BEST.
  • Technical Investments (Green Bar): Indicates how much effort is spent on improving the team, architecture, and environment. Decreasing from the first couple of sprints to a constant/sustainable trend at the later sprints is GOOD.

From the measured items the team can also calculate

  • Done Success Rate: Percentage of Done vs. Committed Story Points. By comparing Forecast and the sum of Functionality, Technical Debt, and Technical investment bars
  • Estimation Effectiveness: deviation of planned hours and actual hours
  • Hours per Points: Can be used for estimating hours of succeeding user stories

I have attached a FREE Template for recording Velocity Histogram.

Please do leave comments on your thoughts about the template and the article.

Scrum on!



Published by agilepinoy

We are Agile Pinoy. We believe that Filipinos can build globally competitive Products, one team at a time.

4 thoughts on “Measuring Team Velocity

  1. Very good and inspiring article ! It’s not easy to find articles like this one about stats topics.

    Also, Velocity/Actual capacity is an interesting value to consider to understand the figures, at least in holidays period.

    Thank you very much

    Liked by 1 person

  2. Thank you for this article, it’s really helpful. I have a question though, how do you calculate the Velocity Points on this histogram? Are they the actual story points at the end of the sprint, I mean do you re-estimate the user stories and recalculate the story points? Because we have on one hand the forecasted points and on the other the velocity points 🙂 thx


    1. hi Carm. thank you for your feedback. forecasted points just mean those stories the team pulled at sprint planning. however, not all plans are perfect. so the actual story points are those that were accepted/closed. some stories are not completed or swapped with other story types in the middle of the sprint.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: