How to use velocity

and 4 common mistakes to avoid

Manuel Küblböck
Backlog stories
Published in
3 min readAug 18, 2016

--

Velocity is a metric that is an indicator for your team’s product development speed per sprint. Its unit is the same as you use for backlog item estimation (often story points) or just the number of items, in case you don’t estimate at all.

As such, it can be used to make predictions on how much you can achieve in the future, or when a specific work item will be finished.

Velocity is a measure of the speed of value creation, not a measure for your team’s performance.

Velocity is great to help your team decide how much to pull in your next sprint. We use a technique called ‘yesterday’s weather’ to predict how much to pull, assuming it will be about as much as you achieved in recent sprints.

Visual indicators in Backlog let you understand at a glance how much work is realistic

Example: In the previous three sprints, you got 19, 16 and 19 story points done, respectively. Averaging (19+16+19)/3 = 18 story points. We assume that you will get about 18 story points done in the upcoming sprints as well.

4 common mistakes to avoid

Velocity can be a useful metric for predicting future performance, but there are a few pitfalls you should stay clear of.

  1. 🚫 Using velocity to measure the performance of a team
    Goodhart’s law applies: “When a measure becomes a target, it ceases to be a good measure.” It will most likely result in the team gaming velocity. If you use estimation, velocity highly depends on it. So, the team will just sandbag their estimates and increase them over time. This will lead to higher velocity, but not more value creation. Velocity measures output, not outcome. If you don’t use estimation and you just count backlog items instead, it will lead to smaller backlog items. As such that might actually be a good thing, but most likely you will end up with too detailed tasks in your backlog instead of user stories that have value to your customers. Comparing velocity between two or more teams is particularly counter-productive because a 3 in one team most likely is a different size than a 3 in a different team.
  2. 🚫 Making long-term plans based on velocity without taking its variance into account
    Your current velocity is an average. Considering the flaw of averages, actual future performance has a 50% chance to be better or worse than your velocity. Depending on your velocity’s variance from sprint to sprint it will be more or less precise for predicting future performance.
  3. 🚫 Including partially done backlog items in your velocity
    Only considering fully finished backlog items in your velocity puts the focus on getting things done, rather than starting lots of things simultaneously (task switching = waste). If you define velocity as the speed of value creation, there is another reason: partially done work creates no value for your users (partially done work = waste). If you often end up with partially done items you should consider splitting them into smaller stories.
  4. 🚫 Using velocity with partially estimated sprints
    If you estimate some types of backlog items (like user stories), but not others (like bugs) and their amount varies significantly per sprint, your velocity will be skewed. This way it won’t be very helpful for predicting future performance.

Even though velocity is a simplistic metric, it is very useful during planning to help teams decide what is realistic for the upcoming sprint and what isn’t.

If you find this post helpful, you might also like our backlog tool.

--

--

Org design & transformation, Agile and Lean practitioner, web fanboy, ski tourer, coffee snob.