Velocity is an empirical measure of the quantity of work that a Scrum team delivers in a given amount of time, typically in a Sprint. It provides a trailing indicator that allows a team to predict how much scope a team will be able to complete in the next interval of time, or Sprint.
Measuring Velocity, and the Average Velocity over a number of Sprints, can help the Scrum team establish more predictable plans. The plan is based on demonstrated delivery performance in the past, rather than wishful thinking. The idea is that if we know the weather from previous days, we can infer that tomorrow’s weather will likely follow the same pattern of the past.
When teams struggle with delivering work consistently every Sprint, a good starting point is to look at the team’s Velocity and how they use it to estimate capacity of an upcoming Sprint. The burndown chart may help to uncover problems with velocity.
Does your team’s Sprint Burndown look like this?
Does every Sprint end with a bunch of work still unfinished?
Do you get a sense that you are over-committing yourself but don’t have a clear idea of how to manage the situation?
You are not alone.
The Yesterday’s Weather pattern
The Yesterday’s Weather pattern may help. Basically, you look at past performance and use that as a baseline to establish capacity for the next Sprint. In this way, the amount of work committed in a Sprint Backlog is no longer based on wishful thinking, the boss’s pressure, or a “stretch goal” you are trying to set for your team.
Now the plan for the Sprint becomes achievable, because it’s based on realistic measurements of past performance. How much work have we demonstrated that we can accomplish in prior Sprints? You may be familiar with the concept of Velocity and measure it in story points. That represents the upper limit of capacity for your next Sprint.
Note the keyword here: upper. This should be your maximum capacity. Don’t go above it, otherwise you set yourself in over-commitment territory from the start. Instead, an argument can be made about going lower than the max. That is, setting a buffer.
When you look at past performance you measure the amount of work completed in prior Sprints. Typically, you may want to look at the last 3 to 5 Sprints, and then take the average. If you are using story points for your estimates, you add up the story points for all the work completed in a Sprint, and that gives you the Velocity for that Sprint. Take the average for the last 3 to 5 Sprints, and you have the Average Velocity for your team. Again, this defines the upper limit of your capacity for the next Sprint.
The key here is to establish reasonable commitments for the Sprint that are based on available capacity for the team. Whether you use story points, no-estimates, or any other practices, try to gauge the amount of work you can reasonably complete in a Sprint and set that as your available capacity.
When teams establish commitments that are too large for them, they over-commit. That means that they set the wrong expectations with their stakeholders, that plans becomes unreliable, and that any promised date is not achievable. Over-commitment also puts undue pressure on the team often forcing the team to multitask, trying to finish everything within the Sprint. Unfortunately, neither pressure nor multitasking are good practice to help the team improve performance.
If you want to help your team improve performance, limit the amount of work they take on in a Sprint. Remove the pressure and the “stretch goals”. Establish reasonable commitments based on available capacity. Support your team in delivering on their commitment. They can always do more work if they achieve the Sprint Goal early. In fact, there is no limit to how much a team can complete in a Sprint. But this is only true if the Sprint Backlog represents a reasonable commitment that the team knows it can complete 100% by the end of the Sprint. Let the team finish the work, and then take on any additional tasks or “stretch goals”.
The Yesterday’s Weather pattern is one of many patterns that successful Scrum teams have demonstrated help them improve their performance.
Real-life story: from 27 to 33 points in 2 Sprints
I would like to share a story about how using the Yesterday’s Weather Pattern can help a team improve its performance. This is a real-life story of a team that was already on Sprint 23 or 24. They had been together for almost a year working on this project.
When I joined the team, I participated at Sprint Planning. The conversation pretty much went like this: The Product Owner came in and said, “Hey team, these are my priorities. I would like for you to do these 57 points, this Sprint.” The Developers looked at each other, and then said, “Okay”. After that, Sprint Planning was pretty much done.
Later in the day, I went into the system looking at metrics for past performance. I pulled the Sprint burndown charts from Jira. As long as you update the data throughout the Sprint, Jira can generate a Sprint burndown automatically. I went in and looked at the Sprint burndowns for the past Sprints and I noticed that this team never delivered more than 27 points. In fact, 27 was the max they ever delivered.
Now, I was baffled because at Sprint Planning, they just committed themselves to 57 points. That was more than twice over commitment. It didn’t make sense to me.
So, I reached out to the Developers and I said, “Can you please explain to me what are you doing?” They said, “Well, the Product Owner is our boss.”
I understood there was no psychological safety and there was no way for the Developers to really push back based on their available capacity. So, I went to the Product Owner and I said, “Look, Product Owner, the team never did more than 27 points in a Sprint. Why did you give them 57? That’s more than twice over commitment. It doesn’t make sense to me.”
The Product Owner says something like this, “First of all, this is my team. I decide how much work they do. Second, if I give them less work, they are going to slack and give me even less. In fact, I’m thinking I’m going to give them even more work next time.”
I said, “Wait, okay, but look, there is a reason why you called me to coach this team and help you improve. What you’re doing doesn’t really help, does it?”
After a little bit of negotiation, he finally agreed to run the next Sprint at a maximum of 27. Now you get it: 27 was not ideal yet because we did not have a buffer on capacity. But still, 27 was much lower than 57 and more closely related to what had been the performance of this team historically.
We ran that Sprint of 27 points, and at the end of the Sprint, the team delivered 30 points. You may say, “Okay, lucky event, one shot,” these kind of things. I get it.
So, we decided to run a second Sprint, also at 27 points of capacity, and the team delivered 33 points. Now you see, in two Sprints, the team was able to go from 27 to 33 points, and that is a 20% increase in performance. Nothing else changed in the team, not the way they worked, not the systems, or the resources. Nothing changed except removing the over commitment.
We removed the pressure by committing to a reasonable capacity that was based on past performance. When the team was able to commit to their reasonable capacity, they were actually able to deliver everything they had scheduled in the Sprint Backlog and more. And over a few more Sprints, the team was able to increase its velocity further to 40 points.
That’s how you help your team improve. That’s the pattern of Yesterday’s Weather. Looking at past performance, to give you a sense of what is the available capacity that the team should really plan for at Sprint Planning.
Anti-patterns for Velocity
Calculating the Average Velocity of a team and using it to establish capacity for an upcoming Sprint is a useful technique to create predictability in the team’s delivery. However, Velocity is often abused, due to lack of understanding, or to pressure from management to establish metrics for performance or productivity of the team.
Typical mistakes that teams make with Velocity include:
Equating performance with Velocity: Velocity is just a planning measure (how much work can we predictably deliver each Sprint) and is not a measure of performance. A higher Velocity does not mean a more performing team (it just means a different way to estimate the work).
Setting targets for Velocity: Someone (typically management) may set the expectation that the team’s Velocity should increase by X% in the next few Sprints. This is also the situation when a project is running behind and the team may be asked to increase its Velocity to deliver on time. This often leads to gaming the system, for example inflating estimates, in order to get to the target Velocity, without any real increase in the team’s performance. Velocity is not directly controllable by the team and it’s the result of several other factors (including team composition, type of work performed, processes used to complete the work, Definition of Done, tools, estimation techniques, etc.).
Equating Velocity to percentage complete: Tracking the amount of work completed on a project and the percentage completion can be a useful indicator of progress. However, in an incremental and iterative context (like new product development), the scope of a project may frequently change due to new ideas, changing requirements, etc. Hence, the target scope should be frequently re-evaluated, as should the percentage complete (if the target moves, so should the path to get there). As your scope changes, and your target moves, your Average Velocity may remain the same. Hence, adding up the Velocities of completed Sprints and comparing to the original target may not give the full picture.
Comparing teams based on Velocity: This is probably one of the biggest misunderstanding of Velocity. Because it represents the amount of work completed by a team in a given Sprint (based on THAT team’s estimates of the work), Velocity only makes sense within a team. Two teams may use different baselines for estimates, have different composition, work on different challenges, or employ different skillsets, hence their Velocity is going to be different. Trying to compare teams using Velocity creates forceful comparisons of apples to oranges, and often results in unproductive behaviors adopted by teams to game the system (if a team needs to increase Velocity to match another team’s, they can inflate their estimates).
Using Velocity to estimate capacity
Velocity is a useful trailing indicator to estimate capacity in an upcoming Sprint.
In a follow-up article, I discuss the differences, and how to calculate capacity so that the plan becomes predictable.
Planning with Velocity and capacity
Questions and answers about Velocity
What is Velocity in Scrum?
Velocity is an empirical measure of the amount of work completed by a Scrum team in a given Sprint. You can add up the number of PBIs completed, or the total number of story points completed in the Sprint. That gives you the Velocity for that Sprint.
The Average Velocity is the moving average of the Velocity of the last 3 to 5 Sprints.
Is Velocity a measure of productivity?
No, Velocity is not a direct measure of productivity. Productivity is a measure of how efficiently resources are used to produce a desired output. It’s often calculated as the ratio of output to input. While it can provide insights into the team’s capacity and performance, Velocity doesn’t account for factors like quality, efficiency, or the value delivered.
How can a team increase their Velocity?
Velocity, in Scrum, is a measure of the amount of work a team can consistently deliver in a Sprint. Here are some strategies to help a team increase their Velocity:
- Reduce waste: Evaluate the processes used to build the product. Identify and eliminate activities that don’t add value to the product. Streamline workflows and reduce bottlenecks.
- Automate tasks: Use tools and technologies to automate repetitive or time-consuming tasks. For example, adopt automatic testing tools to reduce the amount of effort required for manual unit testing.
- Encourage continuous learning: Provide opportunities for skill development and knowledge sharing.
- Empower team members: Give team members the autonomy to make decisions and take ownership of their work.
- Set realistic goals: Avoid overcommitting during sprint planning. Setting unreasonable goals only leads to stress, fatigue, and context-switching. Instead, make sure to establish capacity measures that are predictable and help your team deliver consistently.
- Manage impediments: Remove obstacles that hinder the team’s progress. Anticipate potential challenges and develop strategies to address them
- Review and adapt: Regularly assess the team’s performance and make necessary adjustments. Use Retrospectives effectively to help the team identify and remove bottlenecks that may hinder the team’s performance.
- By implementing these strategies, Scrum teams can improve their efficiency, effectiveness, and overall performance, leading to increased Velocity and better outcomes.
Can Velocity be used to estimate project completion time?
At the start of a project, knowing the Average Velocity for your team and the total scope of work for the project, will allow you to establish the project completion time (e.g. the number of Sprints required to complete the project).
During the work on the project, as scope changes and new requirements get added, you may need to re-establish the timeline of the project. A useful tool for this is a burn-up chart that tracks the amount of work completed each Sprint towards a deadline or a scope target.
What is the maximum capacity for my next Sprint?
The maximum capacity for a Sprint can be calculated from the Average Velocity of a team reducing that number by:
- Any lost work days by any members (planned vacations, Holidays, company events, etc.)
- Buffer on capacity (it’s a good practice to leave a buffer in capacity every Sprint to account for unplanned events or work requests)
Refer to this article for more information on how to calculate capacity for a Sprint.
When teams establish commitments that are too large for them, what are the consequences?
Overcommitment in a Sprint is often interpreted as (or justified by) setting stretch goals, pushing our limits, or management pressure to improve performance. When teams set unreasonable goals for their Sprints, and then deliver less than 100%, that creates frustration, blame, and lack of motivation.
It may also lead to a refusal to follow the correct practices in Scrum: Why setting goals if we cannot deliver on them?
So, avoid overcommitment. Your Average Velocity should always set the upper boundary of your Sprint capacity (i.e. never plan above Average Velocity). Setting unreasonable goals only leads to stress, fatigue, and context-switching. Instead, make sure to establish capacity measures that are predictable and help your team deliver consistently.