Velocity is a metric to measure of the amount of work (output) a Scrum Team can take up during a single Sprint. Velocity is calculated at the end of the Sprint by totaling the “Points” (or whichever metric you have used for estimation) for all fully completed work packets (User Stories or use cases or whatever format used for describing the work). The Scrum Guide does not mention velocity but does talk about the “past performance” to be taken into consideration while doing Sprint Planning. Velocity helps Scrum Teams keep process variance in check and create a basis for short-term forecasting.
Find out if you really need to measure Velocity
Velocity is a forecasting metric to measure of the output a team can produce. Most mature teams and organizations have stopped worrying about the output and instead they focus on value (outcome) that the output produces. The metrics to measure output then become meaningless for these mature teams.
Example – Let us say that this is your child’s birthday and you go to a shop to order a cake. You might end up ordering the best cake with the best design. If you ask most people, what is the outcome? They will answer it as a cake which is actually only a output. However, the real value of the cake is if your child and his/her friends are able to have a great time in the birthday party. The outcome here is a “happy child and happy friends”. Taking this same analogy ahead, if you have to develop a few features, then velocity will measure how many features can be developed. The value-metrics will measure things like “what is the customer satisfaction”, “Have you been able to reduce the feedback interval”, ” have you developed better ROI for customer” etc. So, many teams have moved away from a metric such as Velocity which measures output and instead they focus on more meaningful metrics which measure outcome instead of output.
If you are absolutely convinced that Velocity calculation needs to be done and Output needs to be measured, then use the suggestions in the following article to forecast velocity
Using Average Velocity
Velocity tends to keep going up and down over the sprints. It is better to use an average number to forecast for future sprints. In the below example, the velocity is ranging between 18 and 30 over multiple sprints. The mathematical average would be around 23. We can take the forecasted velocity around 23 for the next Sprint.
Using Running Average Velocity
For longer projects, it is better to take the running average of the last few sprints. The data of sprints done long time back may not give a good picture. Over longer periods, the work changes, people change, complexity changes and the data starts to skew. “Last few” is something that the team can decide, however, it is my suggestion to take not more than 4 sprints data for the running average. In the following example, the mathematical average would not make sense since the velocity is on the rise. Therefore it is better to take the running average of last few sprints (in the below example, few = 4).
Ignoring outliers in the velocity calculations
Sometimes, velocity may go up or down drastically. In this case, it is better to let the numbers stabilize and then use them for the running average calculation. My recommendation is that the velocity number should stabilize for atleast 3 sprints before considering the drastically increased or decreased number.
Considering capacity while calculating velocity
Velocity gets affected if there are holidays or sickness in the team. Recalculate velocity if the capacity of team dips due to various reasons such as vacations, sickness or any other reasons. For example, if it is December and we are working with a team in the western world then it is better to take the capacity in December into consideration. Let us say 30% of capacity is not available then take 70% of the calculated velocity as a forecast for December. Let us say the calculated average is 60 points then if only 70% capacity is available then the calculated velocity would be 70% of 60 points and that is 42 points.
One should consider vacations of different regions and then calculate the capacity available. Let us say that 2 people are working from USA and 8 people are working from Mumbai, India. Then for the 2 people in US, the capacity will dip in December. However, for the team working in Mumbai (8 people), the velocity will dip when Diwali vacation comes i.e. October or November. In this example, the capacity will be more affected as per India vacation rather than the US vacation.
Take out the capacity required for specialized work
Sometimes, there is one-time specialized work to be done. Examples of specialized work could be database configurations, cloud setup, trying spikes, critical defect fixing etc. Let us say, we estimate that specialized work would take 40% of effort next sprint, then it would be prudent to take only 60% velocity for any regular work.
Recalculating the velocity of last sprint in case of adhoc activities
Many times, the team also has to take up adhoc activities. Example of an adhoc activity could be production defect, or a customer visit for some prospective customer, proposal presentation for a new project etc. Let us say that in this sprint, suddenly there was a production defect which took up 30% of your effort and let us say you achieved only 40 points instead of the forecasted 60 points, then the recalculated velocity for the current sprint could be 130/100*40 = 52
Consider usual disruptions while calculating velocity
Many times, the team has to cater to usual disruptions such as production support tickets (if there is no dedicated production support team). It is better to keep that capacity aside instead of considering the entire capacity being available. Let us say, the team is able to get an average velocity of 60 points if 100% capacity is available. If the usual disruptions take up 20% of effort then it is better to consider 80% of 60 as a forecast (48 points). Then if any disruption does not occur then the team can take up 12 points worth of work from the Product Backlog upon completing current work.
Specifically include maintenance work while calculating velocity
When the teams know that their output is getting measured (and rewarded), it is tempting to keeping on accepting “new” work that they can show more output. This then sometimes encourages the teams to give less importance to the maintenance work . This work may include regular refactoring / removal of low priority defects impacting non functional requirements / data and/or code clean up etc. When such work starts getting piled up, team may not notice initially but at times this may be a ticking time bomb that is just waiting to explode. To avoid this, it is very important to discuss and regularly dedicate a percentage of effort for ongoing maintenance work.
Velocity of one team cannot be compared to another team
Velocity depends on skills, experience, complexity of the work that the team performs. Also, when using story point estimation technique, each team decides their own reference as to what a one pointer or what a 3 pointer or what a 5 pointer means. Comparing one team’s velocity to another could result into situation such as comparing apples to oranges.
First find out if you really need to measure Velocity which is an output measurement metric. One must focus on meaningful metrics for measuring value. If you are convinced that you still need to use velocity as a metric then you should not use velocity as a mathematical metric. The math is useful to make a guess as to what the team would be able to forecast in a sprint.