Note: Velocity and Capacity are extensions to the Scrum Guide. Although it’s not a formal part of Scrum, their use is quite widespread and recommended as a best practice.

Velocity

Like a speedometer in a car Velocity helps a Team to forecast how many Sprints they need to develop new features. Following its ups and downs also allows a Team to analyze the progress they make as a result of any recently implemented improvements.

What is Velocity

Velocity is a measure of the amount of work a Team can complete per Sprint. A Sprint varies from team to team but is typically a week or two weeks, with a two-week Sprint consisting of 80 working hours. Just to keep things clear we can use an “hour” to show our speed on the speedometer. But what about measuring the amount of work? There are three basic approaches we can use:

1. Points. The most widely used and recommended as a best practice.

2. Man hours or man-days — a traditional waterfall approach.

3. Count by the completed Product Backlog items — the most recent approach also known as #NoEstimates. This works well for the mature Teams with stable Product Backlogs where the items are more or less similar to each other.

We can measure the instantaneous speed of a car at any time by just looking at the speedometer. Using that to predict how long the journey is not going to be accurate, as the speed constantly changes. So we use average speed for forecasting. The same logic applies to Velocity. After every Sprint, we can easily get the actual Velocity. But for predictions, we should use the average Velocity and re-calculate it at the end of each Sprint.

And while average speed might be helpful in getting an ETA to the end of the journey, it won’t work so well for short distances. The quality of the road may vary, the traffic might increase. Everyone knows that feeling when you run into congestion and realize that the next 10 miles is going to take the same time as the previous 100. And if you try to calculate how many hours to your destination based on the overall average speed, it will almost certainly result in unrealistic expectations. To get a better prediction, we should measure the average speed based on shorter sections of the whole journey. For Velocity we usually consider the last three Sprints, in what we call the “Yesterday’s Weather” pattern.

Velocity in a Sprint

During a Sprint, you might want to know if your Team is able to complete the planned scope or if any corrections are required. The most common approach is to use a burn-down chart. There are three basic burn-down strategies:

1. Burn-down points by the completed Sprint Backlog items. The items must be small enough to be completed within one-two days. Otherwise, bigger items would result in more stair-stepping and less clear burndown line.

2. Burn-down points by the completed end tasks. This implies that Planning Poker is used to estimate the tasks in points. This approach takes more time during planning but doesn’t require small backlog items to have a clear picture for Velocity.

3. Burn-down hours by the completed end tasks. This implies that the end tasks are estimated in ideal hours during Sprint Planning. This is similar to the previous point. Even though this approach is still widely used Scrum Foundation and Scrum Inc. no longer view this as a best practice.

Starting Velocity

For the most accurate forecasting we take the average of the last three Velocity measurements using the Yesterday’s Weather concept. This approach is quite reliable, but isn’t possible when a Team is starting their very first Sprint. There is no historical data which could be taken as an input, so one of the main goals during this time frame is to get that data.

On the first Sprint Planning session, the Team starts by using Planning Poker and coming up with points for each item. Team members often rely on a gut feeling to come up with the total number of the Product Backlog items that they can complete within the first Sprint. During the second Sprint Planning, the Team can use their actual “instantaneous” Velocity for the first Sprint, which increases the accuracy of estimations. On the third — the average of the two passed, which again is more accurate than the previous. Finally, starting from the fourth Sprint, the Team has all the data to make the most precise estimations.

Non Functional Items

Velocity is often mis-interpreted and can create the wrong expectations. At first glance, the Velocity calculation is quite clear and straightforward. When someone hears “the completed backlog items”, in most cases, they imagine functional items. In Agile we care about adding business value by primarily adding new functionality. But that’s not the complete story. Every Development Team always has “non-value” items in their Sprint Backlogs such as:

• technical enablers

• exploration spikes

• refactoring and other technical debt

Not doing such investments means that a product will get blocked or stuck at some point of time. Technical enablers do not give anything tangible to the business right now, but they unblock future development. Exploration spikes are not features that can be demonstrated during the Sprint Review. However, they give a Team vital knowledge of how to do the right things in the right way. Refactoring and technical debt deal with already delivered functional parts are much less interesting than the new features. However, only high code quality makes frequent delivery possible.

Since it’s not something Product Owners can proudly present during a Sprint Review session these non-functional items get much less attention.  To ensure a healthy balance between these non-value and value items, make the Velocity calculation as transparent as possible.  Knowing the Sprint’s Velocity is not enough; show the proportion between these basic non-functional categories. This aligns expectations and helps allocate some part of the Velocity for “technical stuff” in future Sprints.

Alternatively the Team could explicitly agree that Velocity is calculated based on functional items only. Don’t consider any non-value ones in the formula. The Product Owner can then fully use Velocity on just functional features. The Team then runs the risk of losing clarity on why Velocity goes up or down as non-functional items are added to a Sprint.

Velocity and bug-fixing

While bug-fixing can be viewed as part of technical debt discussed above, many treat it as an integral part of the development process. No one is immune to mistakes, especially in a complex software system developed by multiple Teams.

Bug-fixing has an impact on Team’s Velocity. The more defects discovered in a Sprint, the less new functionality the Team is able to deliver. In order to mitigate useless frustrations in this case, it is better to have a clearly defined place for bug-fixing in Velocity. There are three basic ways to achieve that:

1. Include estimations for bug-fixing into every Product Backlog item during Sprint Planning. In case of more complex items, where there is greater risk, allocate more points for bug-fixing.

2. Allocate some fixed number of Velocity points for bug-fixing for all the Product Backlog items in a Sprint (like for the technical spikes or the technical debt).

3. Don’t allocate anything for bug-fixing, so Velocity will be just lower and its oscillations will be less clear. In other words, you do the required bug-fixing every Sprint without reflecting anywhere on the effort spent. This impacts the Team’s Velocity as the Velocity “automatically adjusts”.

Number 3 doesn’t require any overheads,but it isn’t as transparent as the 1 and 2. Let the Team choose the most appropriate option to find their ideal balance between extra overhead vs decreased transparency.

Capacity

Capacity is a measure of the Team’s availability during the upcoming Sprint.

What defines the speed of a car? The most basic is engine displacement. The higher the total volume the engine has, the higher speed a car can reach and the more operating load it can carry. The same is for a Team with its Velocity and number of the Product Backlog items.

Engine displacement is determined from the bore and stroke of an engine’s cylinders and the number of the cylinders. Translating the metaphor back to the Development Team: the cylinders are the team members, the bore reflects the breadth, and the stroke — each team member’s depth of knowledge and experience.

But the Development Team is not an engine, which has the same number of cylinders all the time and can run without stops. Capacity is not a constant for the Team, it varies over time. Yes, the Team has its maximum Capacity when all the “cylinders” are in operation but various factors and conditions are permanently affecting it. And we need to consider these to help make better forecasts.

Variable impact

Basic factors which impact the Team’s Capacity:

1. Number of workdays available in a Sprint for all the Team. The number of days in 2 two-week Sprints may differ depending on:

   1. Common public holidays.

   2. Common company’s events (e.g. celebrations, teambuilding).

2. Number of workdays available in a Sprint for individuals. It depends on:

   1. Public holidays for different countries if you have a distributed Team.

   2. Vacations or time off for each team member.

   3. Time to attend meetings, events, activities outside the Team’s interest (e.g. conferences, self-training, training for other team members, support of other teams).

3. Ramp-up and ramp-down of your Team.

4. Part-time membership of the Team.

Some Teams try to account these variable overheads by adding the corresponding items to the Sprint Backlogs. This approach seems extremely transparent, but it’s not recommended. It stuffs the Product Backlog with items that little or no relation to the Product. Also, it adds useless bureaucracy which are simply not worth the level of transparency. Finally, it can’t be applied to variable overheads such as ramp-up and ramp-down.

There is another more efficient way to account for changes in Capacity and get a refined Velocity forecast. The steps are as follows:

1. Calculate the maximum Capacity of your Team in man-hours, assuming that you have ten working days in a two-week Sprint and all the team members are available.

2. Calculate the adjusted Capacity, considering all the Capacity loss you will have in the upcoming Sprint.

3. Get the ratio of the adjusted Capacity to the maximum Capacity.

4. Apply this ratio to your current average Velocity.

Here is an example:

1. Imagine we have 9 team members, who work within 2-week Sprints 40 hours a week. The maximum Team’s Capacity is: 9 * 2 * 40 = 720 hours.

2. Now imagine, 1 software engineer and 1 business analyst are going to have their 2-week vacations during the next Sprint and all the team will be away on holiday. So, the adjusted Capacity is: 720 – (2 * 40 * 2 + 9 * 8) = 720 – 232 = 488 hours.

3. The ratio is: 488 / 720 = 0.68

4. If the average Velocity for the previous three Sprints was 160 points. Then the refined forecast for the upcoming Sprint is: 60 * 0.68 = 109 points.

Putting Capacity together with Velocity provides transparency and visibility to your Product Owner and Business Stakeholders. Diagrams similar to the one below answer the questions like “why we did so little in the last Sprint” and “why we are able to take so few backlog items to the upcoming Sprint” even before they are asked. Such a clear picture also prevents demotivation of teammates, who may be frustrated for the same reasons. Clarity aligns expectations.

Be careful with this ratio as it may fail. It assumes that all the team members have the same level of knowledge and experience. Rough approximation works fine for a well balanced team. However, if 3 team members (out of 9) decide to have a vacation during the same Sprint, and they are the only software engineers in the Team, it will not adjust the Velocity by 1/3, but will drop the Velocity to zero making the Sprint a complete disaster. The same logic is applied to the balance between junior and senior team members. So, the Team should always think about the impact on Capacity when planning vacations, time off, conferences and other non-project events.

Permanent impact

Examples of permanent impact are regular Scrum events (e.g. Daily Scrum, Sprint Planning, Sprint Retrospective, etc.) and the time needed to prepare them. Like cylinders in an engine which all the time have to overcome the engine’s resistance, similarly, we have the fixed overhead caused by the regular events every Sprint. It doesn’t change, it doesn’t impact the Capacity and the Velocity over time, it is forever. So, there is nothing to do with the fixed overhead. Calculate it once, let everyone be aware of it and then just forget it.

Summary

So now, knowing what Velocity is with all its dependencies. Feel free to use it in the way your Team feels is best.

1. Start with a clear definition of Velocity. Agree with your team on which activities are included in the calculation.

2. Use the instantaneous Velocity to celebrate breakthroughs and adjust the course during a Sprint.

3. Use the average Velocity for planning purposes and evaluation of improvements. Play with the number of Sprints to get more accurate predictions. Remember all Teams have a different Velocity.

4. Consider the impact of variable Capacity. Find your own factors which impact Velocity and define your own approach for planning vacations and other days off.

Finally please remember, Velocity is not a KPI for managers; it is a powerful and helpful instrument in the arsenal of your Team.

Alexander Postnikov