Hey Product Managers, Stop Obsessing Over The Team’s Velocity!
Pawe? Huryn
The Product Compass Newsletter | Actionable Insights and Resources for PMs | Join 80K+ PMs
?? Update 28th October 2022
This newsletter is not active anymore. If you want to receive free PM tips, resources, and advice biweekly, subscribe here: https://huryn.substack.com/
Of course, I'll still be using my personal LinkedIn account ( Pawe? Huryn ).
- - - - -
Velocity is one of the most misused Agile metrics. Managers, Product Owners and Scrum Masters trying to keep it constant at all costs drive their Teams to the abyss of no return.
What is Velocity?
Velocity is an indication of how many Product Backlog Items (e.g. User Stories) were turned into an Increment during the Sprint by the Scrum Team.
Velocity can be measured in several ways. A frequently used metric is the sum of Story Points corresponding to Product Backlog Items completed during Sprint. Some Scrum Teams use the number of Product Backlog Items completed during a Sprint.
Why does it matter?
During the Sprint Planning event past Velocity can help Developers decide how many Product Backlog Items they may forecast for the current Sprint.
“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts” — Scrum Guide 2020
In most cases, measuring Velocity makes a lot of sense. Regardless, it is worth emphasizing that?neither Velocity nor Story Points are part of Scrum. The acceptable approach is for the Developers to look at the Sprint Goal crafted during the Sprint Planning and Product Backlog Items selected for the Sprint and simply say “yes, we can do it”.
What can go wrong?
I’ve noticed that many Managers, Product Owners, and Scrum Masters make these mistakes over and over again.
1. Setting Targets for Velocity
Most often, determining expectations about Velocity comes from the misconception that it corresponds to the “flow of value” delivered by the Team.
Meanwhile, the purpose of Velocity is to forecast how much work can be done during the next Sprint. It tells us nothing about the value being delivered, as there is no direct relationship between the value and the time needed to complete the work.
Velocity corresponds to the amount of work, not the value of work. It is an internal metric and?should never be used outside the Scrum Team.
Setting targets on it can cause adjusting the estimates to “outsmart the system” e.g. by juggling/padding the estimates, rendering the metric useless. Goodhart’s law is an adage often stated as:
“When a measure becomes a target, it ceases to be a good measure” — Goodhart’s law
2. Comparing Teams based on Velocity
Velocity indicates on average?how much work can be delivered by a Team?within a specific period. While it may be tempting to compare Scrum Teams based on their Velocities, it’s important to realize that they are expressed in different, abstract units.
If a Team uses Story Points, these are specific to a particular Team. Likewise, the average size of the Product Backlog Items can vary by domain of work and Team.
Velocity of each Team is expressed in different, abstract units. It makes no sense to compare apples with oranges.
Velocity can also kind of help to understand?how predictable the Team is in terms of delivery. Nothing more than that.
3. Expecting maximum Velocity from the start
Newly formed Teams, starting work on a new project or a new type of work, do not have the data to correctly forecast the future.
“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts” — Scrum Guide 2020
In other words, you have to “get your hands dirty” to understand how to get the job done.
In my experience, when you start working on a new product you can expect more work to emerge than planned. This is also known as?Planning Fallacy .
领英推荐
Usually, a few Sprints are enough for Developers to have enough confidence to better plan the work to be done. However, this is still only a forecast and can vary from Sprint to Sprint, as there is always complexity involved.
4. Expecting that the set scope will be delivered by a set date
Since product development is complex, no one can guarantee what will happen in the future.
“Empiricism asserts that knowledge comes from experience and making decisions based on what is observed” — Scrum Guide 2020
Empiricism recognizes that in complex environments the future is unknown. It cannot be planned, we can only make a forecast based on what has happened in the past.
The farther into the future, the greater the “Cone of Uncertainty ” — as a forecast lengthens, it is increasingly less certain.
That’s why:
“Scrum employs an iterative, incremental approach to optimize predictability and to control risk” — Scrum Guide 2020
In my opinion, planning ahead for more than one month in advance is always guesswork (Cone of Uncertainty). This is partially confirmed by the Scrum Guide:
“Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less (…) When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase”— Scrum Guide 2020
Three final thoughts
To avoid the most common mistakes, here are some things to keep in mind.
1. Commitments in Scrum
Commitment is essential in Scrum. It is worth noting, however, that the?Scrum Team does not make any commitments regarding set scope by a set date.
The Scrum Team?commits to achieving their goals, but the goal is an outcome you wish to achieve. The path towards the goal may change.
“The Scrum Team commits to achieving its goals and to supporting each other“ — Scrum Guide 2020
Scrum Teams also commit themselves to live by the Scrum Values:
There are also other commitments:
their role is to ensure that each Scrum artifact:
“(…) provides information that enhances transparency and focus against which progress can be measured” — Scrum Guide 2020
2. Role of the Organization
Developers are professionals who?respect?each other and the people they work with. They are?open?to challenges and feedback,?focused?on goals, and?committed?to doing their best. They have the?courage?“to do the right thing, to work on tough problems”
For Scrum to work, the organization must give up the desire for strict control, learn to live by the same values.
“When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust" — Scrum Guide 2020
It creates trust. Openness to trust is key for these values to flourish.
3. Velocity vs. Speed
Personally, I don’t like the term “Velocity”. A much better term for what we use in Agile would be “Speed”. In physics, velocity is a vector in space. Speed, on the other hand, says nothing about the direction or whether the direction you are going is the right one.
Are you convinced that high Speed is leading your Team in the right direction?
Never really believed in a rigid artificial thought process like agile. It works much better to educate staff on fundamentals, be clear about what problems you are trying to solve and ask people how they want to contribute.
Head of Engineering at Beforepay
2 年Loved it! Velocity is very often misused by product teams which makes them lose track of the value being delivered. If the team moves together at the right pace (Speed), they will perform better than keep a “target” for a certain velocity.
Development Director at BEC
2 年Great article Pawe?. I think the discussions in the comments raises the needed question - how do we actually get some predictability when forecasting how far away (in time) a certain feature of a scrum team is. Why is this important? Customers who pays for a feature is always interested in when they get what ordered, and of cause, also how much it will cost (time spend tends to equal cost). When working with software, where it is not just "building the same house over again", I think velocity is very useful. But as always, one should never forget the value creation - a fast build piece of software is worth nothing if it does not pass the acceptance criteria.
Engineering Manager at Epikast
2 年Great article. I have seen all those ways of misusing velocity in organizations. Velocity and using it for release planning (when done correctly), can be such a powerful tool in convincing teams to move away from hours estimations and it can be so much more accurate for determining when a project can be done.
Program Manager, Delivery Manager, Project Manager
2 年Fantastic Article! I totally agree, I have seen for some years how SM lost their mind due to strict control in numbers and more important the value. PMO′s can be a nightmare, they don't even understand what we do and how they just want a number and with SAFe is even worst! I am a fan of Serious Scrum