How Not To Use Velocity

In the agile world, there can often times be nothing more misunderstood than team velocity. As most of you know, velocity is the average output of the team based on the number story points completed across a series of sprints.

For those who are new to agile, all development requests are broken up into deliverable features, called user stories of which each have an associated point value determined by the team. For example, if the team delivers 10 points of work in the first sprint, 15 points during the second and 12 during the third, the velocity of the team by this point is 12 (always round down).

Different teams have different values for a point, so let's not dwell too much on the actual definition of a point, but for the sake of the discussion our teams use:

• 0 pts: trivial task, just pound it out
• 1 pt: uninterrupted half day
• 2 pts: uninterrupted full day
• 3 pts: uninterrupted two days

We know there is no such thing as an uninterrupted day for engineers, so points are just indications of general size. How does one task measure up with previous tasks which the team has encountered? Is it smaller, larger or about the same? 

After a few sprint iterations, assuming your team's criteria for sizing remains constant, your velocity will be a decent indicator of how much work it can commit to for the next sprint. 

Naturally, it appears as though there is a direct correlation with points and time so your management group will likely correlate team velocity to efficiency (or lack thereof). This is a very slippery slope that a seasoned ScrumMaster must avoid. Here are some tips to help avoid common pitfalls around people's interpretations of velocity:

Manager: "Why did the team's sprint point output come in lower than the average velocity?"

Remember, velocity is an average and it sometimes takes numerous iterations to get to a useful number. As with every average, there are numbers above and numbers below this line. There are also outliers. It is not unusual for teams to have sprint outputs lower than their velocity. Now, if nothing has changed in pointing the stories or in your team's contributors and you only complete half your velocity you may want to investigate what has happened, but you should be catching these things early and make adjustments as you go.

Management should not be nickle-and-diming the team's velocity, though those who don't come from an agile background will most likely do this at some point. Many from the old school are used to seeing billable hours of work summarized weekly to account for productivity. They like to see where every minute of work is being spent. Beware. This could lead to more questions which don't jive with agile.

Manager: "How can we increase the team's velocity?"

This is a pretty loaded question. For starters it implies that the team isn't doing enough. While that may be a caused by lack of transparency (which is another topic), you must remind them that points are an arbitrary number that are not directly indicative of productivity. If the team catches wind that management feels that they aren't getting enough points completed, guess what they'll do? They'll pad all of their estimations so next sprint they'll come in way ahead of their velocity.

If your process is sound and roadblocks are being navigated efficiently, outside of increasing team resources, there's not much you can to meaningfully increase velocity.

And this is really the entire essence of software development. What do points mean to a customer or internal stakeholder? Nothing. They only care about features and improvements. All that points and velocity do is help us best understand how much can reasonably be committed to. Points give us a general size for a task while velocity provides us a view into how many of these tasks we can complete per iteration. If we're working on the most important features and delivering these every iteration, what does a number mean? Very little.

Manager: "Let's make sure the team commits to the exact of number of points which match velocity."

When a manager approaches the team like this it is another attempt to make sure that developers aren't leaving effort on the table. This is dangerous because it can lead those outside the team providing input on how to best play what I call "Point Tetris" in an attempt to group stories together equaling the velocity.

Remember, the number of the velocity doesn't matter to the end-users; features do. If you are delivering features in top down priority order, nobody is going to complain that the team came in 5 points short of their average velocity. It's imperative that as ScrumMaster you and your business are thinking about software development in terms of features delivered, not story points completed.

Pitfall: Don't ever leave a sprint planning meeting by grabbing stories with just the right amount points matching the velocity and saying "that's it." 

You're forgetting the most important part of each sprint which is the team's commitment. While velocity can guide the team into making an educated decision, it shouldn't force commitment. Perhaps the team feels they can accomplish more features than what matches average velocity. Or maybe less. Either way, it's the commitment agreed upon by the team which provides real value and buy-in. If you try to force the team to commit to something, you've already ruined the sprint. This isn't totalitarianism; there are no executive orders that work in agile. It's freedom of assembly and the right to decide how much the team can do.

If you trust the team to commit to their work load you'll find (as long as they aren't held to the number of points they complete) that they won't sandbag the estimates. Their commitment will mean something to them and they will focus on owning up to their word. 

Velocity is indeed important in helping to estimate how much the team can complete in a sprint as well as how many sprints it will take to finish a project, but velocity is just an average based on estimated arbitrary units of relative measurement. It should never be used to micromanage a development team or worse, individual team members. As someone who has experienced all of the above problems and more in my career, I can assure you that this is a legitimate challenge. It's up to you, as the ScrumMaster, to prevent that from happening.