Agile teams measure the velocity of their sprints. It helps them to plan and track their progress and provides insight for product owners to plan product releases. Can teams also use velocity data when they want to improve themselves? Several authors have written about velocity and shared their concerns on measuring velocity to improve the productivity of teams.
Catia Oliveira wrote about how to calculate and use velocity to help your team and your projects on the Scrum Alliance website. She sums up what measuring velocity can do for teams:
If you know your velocity, you'll have an idea about:
- How much value you've delivered until now (in story points and done user stories), and
- When you'll be able to deliver all user stories in the product backlog, and
- How many story points will you be able to deliver by a certain date.
She also provides a list of factors that can influence velocity:
- Roadblocks -- aka impediments
- Fuel -- motivation, what drives us
- Driver experience -- knowledge/expertise/competence developer
- Car conditions -- dev environment
- Visibility -- project transparency
- Directions -- project objectives
- Traffic/driving rules -- processes
- Destination -- product
George Dinwiddie wrote the blog post tracking velocity. He describes that measuring the velocity by teams can be useful as it provides insight how the team is doing. But he warns against using velocity data to measure productivity:
In the case of velocity, it’s not an analog for productivity. It’s easy to fall into the trap of thinking so. “28 story points is the amount of work we can accomplish in a sprint.” Except 28 points is not an amount of work; it’s an estimate. (…) We can easily manipulate either one by estimating with more story points or slicing the work into smaller stories. It’s so easy, we can do so without noticing or intention to do so.
(…) while velocity may roughly track productivity, it will cease to do so as soon as we use it for that while trying to increase productivity.
In 2012 Tim Ottinger published the blog post 14 weird observations about agile team velocity which contains a list of answers to questions he frequently gets about velocity. He starts by stating that although you can measure velocity, you cannot directly control it:
Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying.
The relationship between improved performance of teams and their measured velocity can be complex as Tim explains:
When a team improves, either the velocity will go up and story points will remain roughly the same or the velocity will largely be the same and the points assigned to a story will reduce. However, quite often both will happen to some degree. This is one of the reasons you can't compare velocities across teams (there are may more reasons).
In the blog post velocity is not the goal Jeremy Jarrell explains why it can be important for agile teams to have a predictable velocity:
Teams that post consistently high velocities are often treated as valuable to the organization. However, those teams that tend to be more erratic…posting a high velocity one sprint then falling off dramatically the next…may not be as valuable as they may first appear.
The reason is that velocity isn’t as valuable as predictability. Much of what we do in agile is done with the aim increasing the predictability of our team. The more predictable a team is, the more effectively we can plan into the future. This lets us take risks more intelligently as well as formulate more realistic strategies based on what our teams can likely deliver in a given timeframe.
Jeremy provides solutions when teams want to become more predictable and at the same time improve their velocity:
Does this mean that a team shouldn’t strive to produce their velocity? Not at all, it means that improving a team’s velocity shouldn’t be its goal. Instead, the team should focus on what it takes to improve that velocity. Practices such as continuously improving the engineering process or systematically identifying and chasing out risk will naturally result in higher velocity.
Nathan Dintenfass wrote the blog post the language of agile is broken in which he mentions some risks when using velocity data to improve team productivity:
Velocity, as a quantifiable measure of productivity, is destructive to the goals most teams set out with in changing their processes. Managers tend to want to increase velocity by doing things like giving bonuses for getting more story points done. That attitude is profoundly misguided, not least because of the obvious corruption of incentives when teams are given reasons to inflate points or otherwise come up with a larger aggregate number for its own sake. What we actually want is frank assessments of relative difficulty in order to accurately and confidently gauge what we can get done in a given cycle. When velocity is corrupted to be something other than a means to achieve decent estimates (and thus commitments) it has a net-negative impact on producing good software.
Tim Ottinger concludes his observations about agile team velocity by stating:
The biggest problems with velocity come from not understanding it, and treating it as a general indicator of productivity or busyness. The secret is to not take it too seriously, and improve your work system and organization instead of improving your velocity.