Myth: Velocity is a measure of a team's performance
Variations:
- Velocity should be constant
- Velocity should increase over time
Follow-up myths:
- Always know your team's velocity
- Velocity-based planning
Category: General Scrum myths
Danger: Moderate
The basis of the myth
Velocity is being propagated by many Scrum trainers and in the Scrum literature, Even scruminc by Jeff Sutherland promotes Velocity as "the Key Metric in Scrum", albeit not being part of the Scrum Guide.Velocity is considered as the "amount of Story Points a team gets Done in a Sprint". From this, teams often derive things like "Average Velocity" as the average velocity of the last 3-5 Sprints as capacity limit for planning.
Why is it a myth?
Not even a concept remotely resembling Velocity, much less all kinds of artifacts surrounding Velocity (such as Burndown charts) are core Scrum. This doesn't mean they are bad ideas. They just aren't necessary. But in some cases, Velocity can turn sour.Assumption #1: The team uses Story Points
Before you can even use Velocity as commonly understood, you first need Story Point Estimation. If you're not doing that, Velocity won't make any sense. For example, when the team estimates in ideal hours: Their Velocity will be constant and irrelevant, because a day's a day's a day.
Assumption #2: Velocity means something
That's basically assuming that Story Points mean something. Story Points are merely estimates - and estimates can always be off. When the estimate was wrong, the Velocity is wrong.
Assumption #3: Apples, Oranges and jellyfish
The very point of relative estimation is that estimates are nonlinear. Try replacing "Planning Poker numbers" ... with Apples for small, Orange for medium and jellyfish for large items: If your can eat 5 Oranges plus 2 Apples, then how many jellyfish can you eat?
Assumption #3: Apples, Oranges and jellyfish
The very point of relative estimation is that estimates are nonlinear. Try replacing "Planning Poker numbers" ... with Apples for small, Orange for medium and jellyfish for large items: If your can eat 5 Oranges plus 2 Apples, then how many jellyfish can you eat?
Consequences
In itself, Velocity poses no problem. It just becomes problematic when it's being used for other things. Such as:
Plans based on average fail 50% of the time!
Just because last time, it worked doesn't mean it'll work again. When estimates are just a crude reflection of what the team knows at the time of planning, chances are that next time, the situation is different. And that can go both ways. A Product Owner is well advised not to rely on historic velocity for planning the future.
Performance monitoring
While Velocity tracking can help the team discover dysfunctions, managers often get tempted to use velocity against the team. When teams get punished for not maintaining velocity, then the metric gets gamed to pointlessness.
Even the seemingly positive reward for increasing velocity can induce highly destructive behaviours.
Even the seemingly positive reward for increasing velocity can induce highly destructive behaviours.
Remedies
Velocity is just a tool to reduce uncertainty and reduce the complexity of planning with little overhead.
Just like it's not worth "producing better estimates", nobody should feel pressured to precisely meet (or exceed) historic velocity. The PO can use Velocity as a crude benchmark for release planning or feature cost, but needs to understand that this ballpark figure is not reliable.
Managers need to be educated to keep their fingers off Velocity for good.
When Velocity figures are abused, the Velocity system should be abandoned by changing the estimation system to apples, oranges and jellyfish, for example.
Just like it's not worth "producing better estimates", nobody should feel pressured to precisely meet (or exceed) historic velocity. The PO can use Velocity as a crude benchmark for release planning or feature cost, but needs to understand that this ballpark figure is not reliable.
Managers need to be educated to keep their fingers off Velocity for good.
When Velocity figures are abused, the Velocity system should be abandoned by changing the estimation system to apples, oranges and jellyfish, for example.
No comments:
Post a Comment