Many teams don’t track their velocity, which can become a bit of a problem because you have no data to look at. You are developing software by trying to guess how many items the Development Team can ship by the end of the sprint. But with Velocity, you have real information that you can use, and that can help you sketch out the way your future sprints will look like.
Velocity is the measure of the amount of work delivered at the end of a sprint. By collecting this data for each sprint, the Product Owner can do medium and long-term forecasting of how their next sprints will look like. It helps the Development Team to do short-term forecasting, that is, how much work they can perform in a sprint.
Velocity is useful as long as we use it for the right reasons. I’ve always thought that having this piece of data to look for in the past, will help me know what we can do in the feature. I’ve never taken this information to my teams to tell them that we have to find ways to improve velocity and make a goal out of it. It is a simple tool that adds a little more detail to the information you already have.
Key notions about velocity
Capacity
The capacity of your team measures the time they are putting into a sprint, and not the amount of work done, as the velocity does. You should consider here the productive hours your team has in a sprint, which generally is 6 hours. The rest of the time is meant for their breaks, lunch, emails, and meetings.
Story Points
Teams are using story points to quantify the estimated amount of work that can be delivered in a sprint. Each team has its own system for assigning story points to an item.
Definition of done
Do you and your team have a well-defined understanding of “Done”? Did you write it down and made it transparent for everyone to see it? If not, it’s time to do it.
So why is this so important for the team’s velocity? Imagine that your understanding of “Done” is to see Feature A into production, and your team’s understanding of “Done” is that writting the code and testing a feature is enough. Will you consider this a done item and include the estimate in your velocity calculation or not? Everyone has to have the same understanding of what Done really is.
How to calculate velocity for teams with no historical data
In general, you can calculate the average velocity after the first 3 sprints, but the more data you collect over time, the better your forecasting will get.
If your team is newly formed, a common practice is to start observing the pattern after the first 3 sprints. During this period of time, they are still adapting to each other’s way of working, meeting cadence, and communication flow. As time goes on, their approach and coordination will improve so it’s very likely for that average to change.
Below is an example of how we calculate the average velocity.
| Velocity | Capacity | |
| Sprint 1 | 18 | 300 hours |
| Sprint 2 | 20 | 300 hours |
| Sprint 3 | 16 | 300 hours |
Average Velocity= Sprint 1 + Sprint 2 + Sprint 33= 18
To find out what the average velocity of my team is, I look at the sprints where they worked at full capacity. I think this allows us to make a better prediction of what will happen when team members are taking a day or two off, in the course of a sprint.
Of course, is not unusual to calculate the average velocity using the first 3 sprints, despite the fact that one of the team members took a couple of days off. Choose what works best for you.
Now that you know your team’s average velocity, you can make predictions for your future sprints. So, let’s say there are 100 story points estimated in your Product Backlog. While the team is working in the same capacity, they will be able to finish the work in about 6 sprints.
Predict velocity for mature teams
Knowing your team’s velocity at full capacity, helps you forecast their velocity in the next sprint. When the capacity of the team decreases, you really want to know what will be the overall impact on the project. The capacity can decrease when team members are taking days off, during holidays or the business doesn’t afford anymore to keep that many people on the project.
Check the table below to see how you can anticipate the velocity, knowing that in the next sprint one of the team members will take one day off.
| Velocity | Capacity | |
| Sprint 1 | 20 | 300 hours |
| Sprint 2 | 20 | 300 hours |
| Sprint 3 | 20 | 300 hours |
| Sprint 4 | 18 | 294 hours |
Full capacity = 5 (team members) * 10 (two weeks sprint) * 6 (productive hours per day) = 300
Next sprint capacity = 5 (team members) * 10 (two weeks sprint) * 6 (productive hours) – 6 (productive hours per day of the team member taking the day off) = 294
Average velocity = 20
Next sprint velocity = Average velocity/Full capacity*Next sprint capacity
Velocity helps you prepare your future sprints
Velocity is assisting the Product Owners by helping them understand what the team can accomplish during a sprint. This also supports them to create the bigger picture of how the Product Backlog Items should be organized throughout the project.
For instance, many times Product Owners are adjusting their release plans based on the forecast they make taking into consideration the velocity.
Team’s Velocity helps you understand if you need to:
Bring in a new team member. If the deadline is tight and the project budget allows it, you can bring in a new team member and this will increase the team’s velocity.
Reorganize Product Backlog Items. You should always have the backlog organized and take care of the most important items first. Even if the velocity of your team is not high, at least you’ll ship the minimum necessary for adding the desired value to the business.
Simplify the functionality to be delivered. Picking certain items and let others for another time doesn’t always work. What can be done here, is simplifying these items by focusing more on those elements that make the functionality work and leave aside more complex scenarios.
Don’t forget to use it for the right purpose and never compare your team’s velocity with that of the other teams. There are different systems, different ways of comparing the complexity of an item with the one of another. And each team should choose what supports them best in doing their job well.
Be careful when you talk about velocity with your team and don’t let them understand that their goal is to increase it. It will just make them assign higher story points to each item and it won’t be beneficial anymore.
Do you and your team track velocity? Are you talking with them about it, or it’s just something that you pursue every sprint? You can leave your comment down below.
