Velocity in Agile is a basic metric that tracks the actual amount of work completed by a team during their sprint or iteration cycles, which span from 1 to 4 weeks. The measurement unit in this system is based on story points. Still, it could also represent hours, the number of user stories, or other forms of effort, depending on what needs to be measured.
When a prospect or management asks, “How much time is needed to make it done?” then the sweating comes. Suppose you are applying the Agile approach in your organization, and you don’t measure the deliverables that the team is capable of delivering for a specific period of time. In that case, it’s time you re-group yourself and apply velocity measurement.
The main takeaways from this article are that you become familiar with the simple process of calculating velocity, the crucial prerequisites for measuring velocity, two agile management tools that incorporate team velocity measurement features, and the origins of team velocity measurement in the Agile methodology.
Table of Contents
How to Calculate Velocity in Agile?
- Step 1: Assign Story Points
The process of assigning story points to user stories happens during pre-sprint activities to establish work requirements and complexity levels. - Step 2: Complete the Sprint
The team performs their work assignments from start to finish during the entire sprint period. - Step 3: Sum Completed Story Points
At the end of the sprint, count the total story points from fully completed user stories. Only finished stories count. Partial completions are excluded. Therefore, the sum of story points or hours for completed user stories represents the iteration/sprint’s team’s velocity. - Step 4: Average Across Sprints
The process of calculating average velocity demands the combination of story points from multiple sprints with the same duration, which are then divided by the total number of sprints (determining average velocity). The method establishes a reliable baseline for future sprint planning.
Average Velocity = Total Completed Story Points / Number of SprintsVelocity is primarily a planning tool, not a measure of the effectiveness of a team. It helps teams predict how much work they can take on in future sprints, forecast delivery dates, and identify trends in team performance. It is not a direct measure of productivity but rather a guide for sustainable pace and resource allocation.
Having a value for average team velocity can be very helpful in providing timelines and costs for the clients during the pre-sales and sales phase. So, don’t delay the process of measuring velocity. Calibrate the process and onboard your team about how to estimate the required effort for dealing with user stories or tasks, measured in story points or hours, and kick off the sprint/iteration.
Calibrating Estimation: How to Estimate?
Calculating the team’s velocity and average velocity of the team over time is an easy job, requiring discipline in feeding whatever system/tool you use with relevant data.
The real thing and the most significant challenge here is how to standardize the assessment and estimate the complexity of a user story or work item.
Estimating User Stories For The First Time
When a new team starts a new job (project/context) and needs to estimate the work, it’s crucial to calibrate the minds of all involved parties on what must be taken into consideration when estimating.
Gather the team and clarify what should be taken into consideration while estimating the sum of complexity, uncertainty, and required effort. Based on personal experience, the following items have to be taken into consideration:
- People’s availability
- Take into consideration administrative time (meetings, pauses, reporting)
- Learning and researching parts that are not clear and straightforward
- Creating documentation
- Technical debt
- Dependencies of external systems and organizations
- Buffer
The approach of calibrating the way of doing estimations and keeping it consistent will avoid inconsistent story point estimation, which has a direct impact on the quality of the Velocity tool.
After the calibration, identify one user story around which all involved parties have a clear understanding of what is expected and what has to be done to provide a solution. Play Agile Poker, and set story points for that user story. Continue to have fun playing Agile Poker to estimate all other user stories against the first one. That first user story you will estimate will be a referential value for assessing and tweaking the rest of the user stories.)
Tools for the Perfect Velocity Report
The following section shows how two agile management tools for big technical teams measure team velocity. I chose Microsoft Azure DevOps and Atlassian Jira.
Microsoft Azure DevOps Velocity Feature
One of my favourite modern tools for agile planning. The integrated feature for measuring team and iteration velocity is straightforward to use.
- You can find the velocity feature under the Backlogs menu, Analytics tab.
- I really love that you can measure the velocity for epics, features, and stories as well.
- It’s possible to measure by story points or by the number of completed work items for the user stories.
For the epics and features, it’s likely to be measured by business value or effort. - PRO TIP: It’s crucial to keep your Azure DevOps instance in good shape and update it daily. The Velocity feature can measure if the completed work items are late or not, and that’s based on when you change the status of the work items.
I recommend setting the team members’ mindset to update their assignments daily before they close their laptops and complete their working day. - You can clearly see the average team velocity based on the number of the last iterations (sprints).
Atlassian Jira Velocity Feature
Jira is a complex tool that offers high flexibility. In the context of a velocity measurement tool, I like the option to use velocity measurements with estimated hours. What you need is to set the space’s feature “Estimation” to Time instead of Story points, and you are ready to use hours as a unit of measuring velocity in hours instead of story points.
- The velocity report in Jira is located under the space’s reports feature and is straightforward to use.
- The useful commitment indicator represents the planned scope of work.
The Roots of Velocity
Velocity came from Extreme Programming (XP), developed by Kent Beck in the 1990s during his work on the Chrysler Comprehensive Compensation System (C3) project. The concept first appeared as a replacement for an earlier metric known as “Load Factor” – read more in “eXtreme Programming – An Overview” by Thomas Dudziak. (NOTE: Don’t get confused with the “load factor” term from electrical engineering.) It was a straightforward idea to track how much work a team gets done in each sprint. Velocity measurement helped teams plan better.
But behind the scenes, this idea isn’t so new. It connects to Operations Research (OR). Operations Research is a discipline of applied mathematics that uses analytical methods like mathematical optimization, simulation, and statistical analysis to improve decision-making. This math-based field started during World War II to solve complex planning problems. OR uses data and models to improve decisions. In Agile methodology, velocity plays a similar role. Team velocity represents team output in numbers, and it’s helpful for better planning and estimating the future scope of work, based on the historical data in a context (the numbers help predict future work). Just like OR, it’s about making wise choices with limited time and resources.
So, while velocity may seem simple, the actual truth is that it’s backed by deep mathematical thinking. Agile borrowed a classic planning trick and made it easier to use.
Adaptive Software Development (ASD), founded by Jim Highsmith, shares many of the Agile principles with XP. Both ASD and XP influenced the creation of the Agile Manifesto.