5 Ways Scrum Teams Misuse Velocity

Misuse of velocity seems to me to be one of the most common mistakes scrum teams make.  Many developers, scrum masters, product owners, and managers misunderstand the purpose of this metric, or measure it in such a way that it loses its meaning.  I think it’s time to go back to basics on what velocity is and how it should be used in a modern scrum team.
 
Velocity is a simple measurement of story points completed in an iteration.  When a team is trying to decide how many user stories to commit to at the start of a sprint, looking at “yesterday’s weather” (another term used for the previous sprint’s velocity) can be a decent guiding factor.  Most scrum teams use their previous sprint’s velocity as a rough estimate of how many story points they can commit to in the new sprint.  Velocity is not the only factor to consider when committing to a new sprint of work, but it’s usefulness comes from being an empirical observation of what actually gets done; it doesn’t depend on gut instincts or predictions.
 
If velocity is so simple, what could go wrong?  This article will look at the top 5 ways scrum teams misuse velocity and how to correct them.

1. Not using velocity to predict

Hands down the number one mistake I see scrum teams make with velocity is not using it at all.  So frequently, teams will diligently measure their velocity at each sprint review, but when it comes time later that same day for sprint planning, they will forget to look at the number when pulling in work for the new sprint.  Often, teams fall into a habit of bringing in some round number, for example, 30 points every sprint, and they follow that number even while their velocity fluctuates between 10 and 40.  They might not even take into account how many story points were carried over from the last sprint!  
 
We often feel embarrassed or disappointed when our velocity shows that our estimates have been too optimistic, but it is crucial that we stay agile and adapt in these situations.
 
There’s a simple fix for this problem: velocity is a useful tool, but only if you use it!!  Begin every sprint planning meeting by determining how many story points ought to be brought in. Then, when the team has finished selecting new work, remind yourselves again what your velocity is and discuss whether you have been realistic with your sprint commitment.

2. Defining story points in hours or days

The first mistake scrum teams often make during iteration zero is to equate story points with an arbitrary number of hours or days.  When a story point is defined as x number of hours, why not just estimate your stories in terms of hours?  If that seems like a good idea, perhaps we should review why we use story points in the first place.  There are two key reasons why agile teams use story points rather than hours when planning sprints.  
 
First, a story point measures size, not time.  If there were a secret formula to guess how long a task will take, corporations would have found it by now, and we’d all be getting a lot more work done.  Unfortunately, it’s simply not possible to look at a user story and accurately predict the number of hours it will take.  However, it is possible to measure its size.  A user story’s size can be measured however you like: by the number of different screens affected on an application, by the number of processes or services which will be affected, or even by the number of developers, testers, and documentation writers who will take part in completing the story.  A story which requires some “backend” and “frontend” work, a series of test cases to be executed, and a page added to the user manual would certainly be considered larger in size than a story which only requires a backend developer, but if that backend developer is a fresh co-op, his “small” story might take a whole summer.  We use story points to measure size because our estimates of size can be much more accurate and therefore much more useful than our estimates of time would be.
 
Second, a story point has no absolute meaning; it derives its meaning from relative comparisons.  Humans are much better at determining the size of things relative to each other than they are at guessing an “absolute” number.  For example, if you asked 10 people to guess how many jelly beans there are in a jar, the estimates would vary by a whole order of magnitude.  But if you showed them two jars and asked which one had more jelly beans, all 10 would likely be able to guess correctly.  By asking the development team to guess the size of stories in relation to each other (rather than picking a unit of measurement and judging each one on its own), you take advantage of the human brain’s natural proficiency for comparing the sizes of similar things.  
 
The next time your development team meets for sprint planning, begin by making sure everyone is on the same page.  Story points are a measure of relative size.  Begin by picking out the biggest and smallest stories to be estimated, and assign to them the biggest and smallest numbers of story points you wish to use (some teams range from 1 to 8, others may use 2 to 13, or even 0 to 100… remember the actual numbers don’t matter because it’s all relative anyway).  From there, compare the remaining stories to the two stories you’ve picked out and to each other, until every story has an estimate that roughly corresponds to its relative size.

3. Using velocity as a performance metric

Too many development teams see velocity as a performance metric.  Managers brag about their team’s velocities to each other, scrum masters encourage their teams to “work a little harder this time” to improve velocity, and developers see their own personal velocity as a point of pride or use it as evidence when looking for a raise.  This mistake can be compounded by thinking about story points in terms of time rather than size.  Managers can often be frustrated when a task that was estimated to take one day ends up taking a week.
 
The problem with giving so much weight to velocity as a performance metric is that it loses its usefulness as a prediction metric.  When a team feels pressure to raise their velocity, all the team has to do is overestimate the size of their user stories.  This leads to inaccurate predictions in the short term, as fewer stories are pulled into a new sprint because their size is inflated beyond reality.  In the long term, the team seems to be getting more story points completed, and the velocity is now a “bigger number,” but in reality the team isn’t doing any more work than they had been doing before.
 
Another problem is that the development team can be made to feel discouraged or “at fault” when a sprint ends without all the stories completed.  Truly Agile development teams, from top to bottom, understand that predictions cannot always be accurate, and it’s not worth playing the blame game when the occasional story gets carried over to the next sprint.  Carrying stories over is a natural and frequent part of the scrum process, so if developers blame themselves or others every time a story doesn’t quite make it to “done,” the team is going to be full of resentment.  
 
Velocity does measure past performance, but that measurement should exist only for prediction.   If your organization is comparing velocities over time or across teams, or talking about trying to “increase” velocity, it fundamentally misunderstands the simple purpose of this tool.  Do not fall for the temptation to keep score or get competitive.  Any increase in velocity comes with a cost, either monetary (hiring more developers) or qualitative (cutting corners to get things done).  The goal is predictable development, not ever-increasing speed.

4. Averaging out velocity over several sprints

Google “velocity in scrum” and you will find countless articles claiming to explain how velocity works.  Almost all of them have some version of this innocuous-seeming statement: “One sprint isn’t enough time to measure a velocity.  After several sprints, calculate an ‘average velocity,’ and use that to predict future sprints.”  This advice is everywhere, and it’s a big pet peeve of mine.  The only reason why the most recent sprint alone wouldn’t be useful for comparison to the new sprint would be if sprint velocities go up and down a lot.  Why do we take it for granted that sprint velocities vary by so much that an individual sprint velocity isn’t sufficient?
 
I’ve observed several scrum teams in action, and unfortunately the reality is that many of them do suffer from this problem.  These teams alternate between sprints where they start a lot of stories and sprints where they finish a lot of stories, so some sprints have a velocity of 0 and others have a velocity well above what they could actually complete in two weeks time in a vacuum.  Sometimes, a scrum team starts a bunch of stories and finishes none of them for the next several iterations, but they keep pulling in new stories every planning meeting because “that’s what the meeting is for.”  
 
Invariably, these teams find themselves using a long term average of individual sprint velocities to determine their “real” velocity, in order to smooth over the peaks and valleys of their development process.  I’ve worked on a scrum team that took a six-sprint (twelve week) average of its velocities, but the personnel assigned to the team changed about every four weeks, so the average was including sprints by entirely different people!
 
Well that’s a bit of an extreme case, but what’s the real problem with averaging out those “good sprints” and “bad sprints”?  The problem is that that’s not Agile.  Waterfall is the development process where you are judged on what gets done eventually.  Agile is the development process where you are judged on what gets done each iteration.  If you try to ignore the sprints where you get little to no story points completed, you are ignoring the times where your team is least Agile.  Ignoring a problem is no way to solve it.
 
The proper way to address a situation where velocity sprint-to-sprint varies by more than a few points is to discuss as a development team what is causing some sprints to complete more work than others.  Are the user stories too big?  Are some members of the team prioritizing new work over closing out old work?  Are there old stories that are waiting on client feedback or input from outside the team or otherwise blocked?  Is there a process for quickly resolving blocked work?  Questions like these can help a team smooth out their process and work towards the ideal agile development process: sprints where a similar, predictable amount of work is completed every time.
 
One of the biggest contributors to the “roller coaster” velocity phenomenon is the last item on our list...

5. Failing to re-estimate stories that carry over to the next sprint

I believe that it is crucial to a scrum team’s success to be honest with itself.  A core principle of agile and scrum is that work isn’t valuable to the customer unless it’s done.  For this reason, I strongly advocate re-evaluating user stories when they are carried over to a new sprint.  If an 8 point story only has 1 point of work left, then it’s a 1 point story for the purposes of this new sprint.  Crucially, the other 7 points disappear: they do not get added to last sprint’s or this sprint’s velocities.  This has not been a popular suggestion on some teams I’ve been a part of, and I may have ruffled your feathers by suggesting that you not keep track of points that have been done, but hear me out.
 
When I recommend to scrum teams that they re-estimate remaining work for stories at the start of each sprint, the responses I receive are indicative of all the problems we’ve discussed in this article.  I recall one impassioned argument I received from a developer once when I made such a suggestion:
 
“If you cut out the points for the part I already did, then I won’t get credit for all that time I spent last sprint!  The work wasn’t done in this sprint, but it’s better to count it in this one than never at all, because it all gets averaged out anyway!”
 
Note that he sees velocity as “credit,” in other words, a measure of his performance.  He sees story points as units of “time spent” rather than “work completed.”  He works on a team that averages out velocities in order to avoid worrying about the sprints where nothing gets done.
 
Once we developers remind ourselves that velocity’s only use is to predict future work and not to measure our productivity, we can take some of the emotion out of the conversation and go back to the agile principles.  If the story is only half-complete, then, frankly, what’s been done isn’t “done.”  The time spent in the last sprint did not contribute towards the sprint increment, because the story was not delivered.  If that work from the last sprint is included in that sprint’s velocity, we might as well grant points for all the other time spent by developers that didn’t contribute to the sprint increment.  If that work is instead bundled into the new sprint, then the velocity will wind up being higher than the team can reasonably expect future sprints to achieve, which makes it useless for prediction.
 
Remember: velocity is the number of story points done in the most recent sprint.  All it can really do is tell you roughly how many story points you might expect to complete in the next sprint.  If you allow it to remain that simple, then there is no reason to fret over the story points “lost” when you re-evaluate your estimate when a story is carried over.  You are simply honing a predictive tool in order to maintain its accuracy and consistency.
 
Did I provide some insight you can use with your current scrum team?  How does your team use velocity?  What other mistakes do scrum teams make when using velocity?  Leave a comment and share your experiences!