Story Point Velocity: Outpace the Snail

Does your Sprint sometimes seem more like a crawl? Are you getting jeers from your stakeholders about how your delivery rate shouldn’t be described as “Sprint”? There might be a metric that can help your team improve their delivery rate. But be forewarned, using this measurement too long might do more harm than good.

What is Sprint Velocity?

Velocity is the number of story points completed in an Iteration (or Sprint).

As I pursued around the interwebs, I realized the definition provided by a lot of the top-ranked pages was slightly off, in my opinion, so I pulled this from Mike Cohn’s book User Stories Applied.

Average velocity is the average of the team’s past Sprint velocities (usually limited to the past three).

When calculating the average sprint velocity, a limit is typically applied so that we have enough data to get an average. However, we’re still focusing on recent data, which will account for any team performance improvements.

Origins of Sprint Velocity

Here is what the Scrum Guide has to say about velocity:

” ”

-Scrum Guide

Huh? What’s that? Oh Yeah, velocity isn’t mentioned in the Scrum Guide, and in fact, neither are story points, or user stories, for that matter.

As it turns out, user stories and story points are all brainchildren of Extreme Programming (XP). Story Points were invented by Ron Jefferies to temper stakeholder expectations and separate estimates from the clutches of calendar-based assumptions.

Velocity became a metric to track how much estimated effort was completed in each Iteration. I say estimated effort here because there is no way to track actual effort. Story Points themselves are intangible, and no monitoring software can measure actual story points in the same way we measure typing speed in words per minute.

Expected Benefits of Tracking Velocity

Three potential benefits can be recognized from tracking velocity.

1. Validate process improvements
2. Forecast delivery dates
3. Motivational insights

Validate Process Improvements

Shifts in velocity between Sprints can be an indicator of whether empirical experiments are having the desired impact. It’s helpful to have a metric we can point to and ask: “Is that better or worse?”

Forecast Delivery Dates

Stakeholders are always going to want to know when something will be done. Although velocity isn’t the most accurate forecasting method, it is one of the simplest. Using velocity to forecast delivery can help answer those burning questions, but expectations should be tempered, and we should establish that this is a forecast and not a guarantee.

Motivational Insights

Teams new to agile, especially Scrum, can begin to experience change fatigue. So much will change in the way we do our work, and it can be hard to see the benefits of these changes right away. Often Scrum, in particular, feels bloated with its four prescribed meetings.

If the team can see a metric improving over time, it can help boost their confidence and reduce transformation agitation.

Common Pitfalls of Tracking Velocity

There are three common pitfalls we should consider carefully before tracking velocity.

1. Punishment for Performance
2. False Accuracy
3. Cross-team Comparison

In some circles, people go as far as to consider tracking velocity an anti-pattern, and after my years of experience watching management do their best to misuse these numbers, I believe I’m starting to agree with this stance.

Punishment for Performance

There is a tendency to start to use velocity as an individual performance metric, which is not really its intended purpose.

First, story points are an estimate. If you owned a restaurant, you might think that tips earned would be a good indicator of the performance of the wait staff (high performers should receive more tips). However, tips have an actual quantitative value. What we’d actually be doing, in the case of story points, is asking the weight staff what they think they’ll receive in tips and using that number as an indicator of performance.

Trying to look at individual performance has another flaw that is commonly overlooked. As a waiter, you notice a table that’s not yours is occupied by impatient customers with empty drink glasses who’ve set their forks down and are frantically looking around the room. Across the aisle, the table assigned to this waiter is full of happy smiling people who’ve just started digging into their food.

As the ower, which table would you want the waiter to check on first? As the waiter, compelled to maximize the tips you think you’ll get, which table are you incentivized to wait on first? I’d wager the two are not the same.

Tracking individual velocities is counterproductive to collaboration.

A third side-effect is that we’ve just driven the wait staff to pad their estimates. If I’m going to get rewarded (or at least not punished) based on how many tips I think I’ll receive, and I’m the one reporting this number, I’ll just make the number higher. At least high enough that management leaves me alone so I can focus on my real job.

False Accuracy

As a guideline for predicting when we’ll be done, velocity is a pretty weak concept, and there are better alternatives (see using velocity to forecast delivery).

A weird phenomenon caused by measuring discrete numbers gives the estimate a sense of mathematical legitimacy.

Compared to teams using t-shirt sizes for estimating, story points are woefully misunderstood. If I told you our work this Sprint was two XL t-shirts, 1 small t-shirt, and a halter top, the language communicates the impreciseness of this estimate.

Somehow though, even though we call them story points - a term I previously thought was silly, stakeholders somehow convince themselves that these estimates are exact.

Cross-team Comparison

This pitfall is also related to the impreciseness of story points. Like smidgen, pinch, and dash measurements, story points have no precise definition. They are meaningful only to a specific team and cannot be translated across teams.

When you look at one team’s velocity of 69 and another team’s of 42, you can’t make inferences about these measurements the way you could for actual mathematical numbers. The team that completed 42 story points may have, in fact, delivered twice the customer value as the team that yielded 69 points.

Like comparing one recipe from each of my grandmothers, a ‘dash’ from my paternal grandmother may be the same, less than, or more than a ‘dash’ from my maternal grandmother. The odds that they are the exact same measurement are actually pretty slim.

How to Calculate Sprint Velocity

Velocity is calculated by summing the number of story points completed in a Sprint.

Note that partially completed or incomplete stories do not count toward velocity.

In the example above, the team has a total of five stories that were planned for the Sprint. Of the five, three product backlog items were completed. The sum of those completed story points (8, 3, 1) is 12. Thus, the team’s velocity for this Sprint is twelve.

If we look at the Scrum Team’s past 3 sprints, we can see that they had velocities of 21, 20, and 32. So their average velocity ((21+20+32)/3) = 24.33 or 24 for simplicity.

How to Stabilize Velocity

If your chart looks like this, you might have a problem.

In an overly simplified perfect world, I could say that we’d like for your velocity chart to look like this:

If you’re a management type that just fell out of your chair after seeing that chart because you think this looks like a stagnant team, you probably want to skip to the how to improve velocity section.

Let’s talk about why this diagram makes sense for everyone still here. There are a couple of root causes for erratic jumps (valleys and peeks in the chart).

1. Your development team has a lot of carryover from Sprint to Sprint
2. We’re underestimating our user stories
3. We’re unable to resolve blockers promptly

Given that agile approaches are based on empirical practices, we expect the team to learn from their experience over time and begin to rectify these three leading causes of unstable velocity.

In the beginning, we’d expect there to be a time frame where we’re learning how to size and estimate stories. Hence the velocity chart above shows some erratic behavior in the beginning. We expect to improve our estimation practices over time; thus, the velocity starts to flatline eventually and becomes consistent.

All the things we can do to prevent carryover will contribute to the consistency of team velocity over time. If your team is struggling to improve, consider these suggestions:

Make sure your team is leveraging retrospectives. You need dedicated time to discuss how to improve your processes. If you don’t make time for this, change will never be prioritized. Focus on process improvements. Stay away from the blame game and finger-pointing. Find a way to change your process to force the behaviors we want to see.

Set SLAs for the removal of blockers. Any blockers that can’t be removed in that period of time should be discussed in the retrospective to determine the root cause and remediation steps.

Discuss carry over with the team. Determine what prevented us from completing work within the Sprint. Establish experimental process changes to reduce the frequency of uncompleted work.

Establish a story point limit for Sprint Planning. Requiring that stories greater than a specific point value be split into smaller bits can help flush work through the process.

I feel like it’s necessary to express that we don’t want the team’s focus to be on achieving a stable velocity just to have a stable velocity. Focusing on improving a metric can be a waste of time. Velocity is just an indicator of what might potentially be an opportunity for improvement. Our focus should always be on delivering valuable software.

Realistically, an agile team’s velocity will fluctuate from Sprint to Sprint, but a stable velocity will help us make better forecasts and accurate plans.

How to Improve Velocity

Some of you may have unrealistic expectations of what a velocity chart should look like over time.

One article suggests that the team strives to increase velocity by 10% each Sprint. On the surface, this might seem like an admirable goal. After all, it is true that Scrum relies on empiricism and that we should strive for continuous improvement. Therefore, over time, we might expect to see an increase in customer value.

However, story points measure complexity, uncertainty, risk, and effort. These are estimates for the amount of work we believe it will take to implement the requested functionality. When we estimate sprints in terms of average velocity, our sprints are time-boxed to some number of calendar weeks. There will be a limit to how much effort the same team can reach in a fixed time period.

Let’s discuss this in terms of cars for a moment. I’ll admit that I was a bit of a speed demon in my younger years. Speed limit signs were blatantly ignored. For serval months, I was a single point away from losing my license due to speeding tickets. As it turns out, there are laws put in place to limit how fast we drive to protect the safety of ourselves and others.

Faster isn’t always better. The faster we go, the more risk we take on. Scrum Teams will start cutting corners to meet expectations. Quality will drop, and technical debt will be introduced. These are all expected negative consequences of putting undue pressure on speed vs. value.

On top of that, constant pressure for more, better, faster can lead to attrition which definitely does our delivery rate no favors.

Returning to our vehicle-based metaphor, cars do have a top speed. If all other limits were ignored, the vehicle itself would have a top speed. Cars aren’t built to withstand rocket speeds. Parts will start to break down, and the vehicle’s structural integrity will be compromised. Eventually, we’re just left with a pile of parts.

So fine, if we agree to a top speed’s existence, how do we know when we’ve reached that point? All the same techniques for stabilizing velocity will help us improve our process and eke out all possible throughput.

If you’re looking for other experiments with your team, you can also try implementing Kanban. It works alongside Scrum and provides additional metrics and processes to hone in on opportunities for improvement.

Velocity Based Sprint Planning

Velocity-based Sprint Planning uses the development team’s average velocity to forecast how much work the development team can reasonably commit to in Sprint Planning.

This Sprint Planning approach is commonly referred to as using yesterday’s weather.

Some agile influencers recommend capacity-based Sprint Planning as it’s believed to be more accurate. In my experience, velocity-based Sprint Planning wins out due to its simplicity. It can be challenging for teams new to agile to have the detailed level of conversations needed to get capacity-based planning right. On top of that, it’s a very time-consuming process. It’s hard for me to justify the cost of a meeting that involves that many high salaried people for that long. Especially when the whole team dreads the event. I think your mileage here will vary depending on your team and your culture.

Using Velocity to Forecast Delivery

Average velocity can be used to forecast delivery dates by dividing the story points on the product backlog by the development team’s average velocity.

In this example, the team’s average velocity is 12. There are a couple of upcoming releases that we want to forecast. The first one has 18 story points remaining, and the second one has 64 story points remaining. By diving 18 by 12, we can forecast that the first release might be delivered in two Sprints. By summing both releases (18+46) and dividing the result (64) by 12, we forecast that the second release might be delivered in six Sprints.

There are some drawbacks to this method of forecasting. First, it suffers from all of the inaccuracies discussed previously with story points.

Second, it assumes that we have all requirements documented, there will be no unknowns that crop up, and there will be no changes in team makeup or attendance (i.e., holidays or sick time).

Third, it requires us to estimate the Product Backlog to the point of the planned release. This can be very wasteful, from creating the user stories to estimating them. Product backlog items that aren’t on a near-term horizon are subject to change, perhaps frequently; therefore, management and re-estimation of those stories could require a lot of future effort.

Unfortunately, there is no sure-fire way to predict the future.

Assuming that the team will be able to accurately and consistently predict the future is an unreal expectation that will leave everyone dissatisfied.

It’s similar to getting upset with the meteorologist for not getting the weather 100% correct.

Velocity is, at best, an entry-level way of forecasting. If you’re looking for something more accurate and still lightweight, I recommend checking out more mathematically backed methods like Monte Carlo Simulation.

Velocity as an Anti-Pattern

Some people suggest that velocity is an anti-pattern and should only be a stepping stone to something better.

And I’m not the only one that feels compelled to warn others of the dangers of inappropriate use of the metric.

Before you jump straight into using velocity, I recommend having your messaging straight. You want to use terms like “forecast” vs. “deadline.” It’s also helpful to coach your stakeholders to recognize the difference between a commitment and a guarantee.

Works Consulted

• Scrum Guide
• Don’t Abuse the Velocity Metric
• Story Points & Velocity are a Sign of an Unsuccessful Team
• Story Points Revisited
• Kanban: Successful Evolutionary Change for Your Technology Business
• User Stories Applied: For Agile Software Development
• Velocity
• UserStory
• Why We Need to Stop Talking About “Carryover”
• Yesterday’s Weather
• Quantifying the Uncertainty: Monte Carlo Simulation
• Why I Prefer Capacity-Driven Sprint Planning

TLDR

An agile team’s true objective should be to deliver as much customer value as quickly as possible. If you feel like your team is moving at a snail’s pace, tracking Sprint velocity may be a good stepping stone metric that can help your team discover opportunities for improvement, but prolonged use exposes the team to the risk of misuse. If you choose to use this metric, have a plan to transition to something more sustainable in the not too distant future.