This is the final article of this series.
The first article set the terms and language that I used when using Velocity as a metric with Agile teams. In short, the main point of the article is that there are three types of Velocity involved:
- Daily Velocity
- Sprint Velocity
- Average Velocity
The second article described the information contained in each metric and how to use it to improve team productivity.
This third article contains some Q&A that are commonly asked when dealing with velocity.
Can I use sprint velocity (or average velocity) to compare teams productivity?
The quick answer is NO. And the root cause is the use of Story Point as a unit. A Story point is not a standard unit of measure, and its meaning varies from team to team. For an organisation to use velocity to compare teams’ productivity, first it needs to invest in normalising the meaning of a story point across the organisation. And even then, it must be careful not to confuse variation with signal.
Another dangerously close issue is to set artificial targets on velocity. Doing so puts your teams under the effects of Goodhart’s law: “When your measures become your targets they cease to be good measures”. There is a lot of information that is observed when velocity variates. Don’t lose this information by setting artificial targets.
When calculating Sprint Velocity, what counts as a completed story point?
Only thighs that add value.
This means, completed stories that fulfil all criteria of Done and are ready -or have been- delivered.
Things that should not count include:
- Partial stories
- Things that do not add value
- Defect correction.
Recommendations to estimate sprint velocity?
Focus on estimating the work, not the velocity. A sprint should fulfil a goal. Focus on selecting the stories that deliver that goal, then look at the different flavours of velocity to assess the feasibility of the story selection process.
