Your Scrum team's velocity and how to misuse it.

Your team has a velocity, whether you choose to measure it or not is irrelevant. On an average day, your team decreases the amount of work they have left in a release or a sprint. The average amount they decrease that work remaining per day is the velocity of that team.

This shouldn't be new information to most Scrum teams (if it is then let me know) but something I run into on a frequent basis is the misuse of velocity. Let's run through a couple examples:

Individual Velocity: This is by far the most common question I get about velocities and the simple answer is that individual velocity is not a meaningful measurement.

Let's say that we have a developer named Bob. Bob's a fantastic developer and can think his way through very complex problems, build amazing algorithms and writes beautiful easy to read code, but he's never spent a great amount of time with C# which the current project is built in. Luckily Bob's part of a great team, they interact in a really meaningful way and as a result Bob still writes great code and he's getting up to speed in C# as his team can help him fill in the gaps when he's struggling with the language. We'll say that based off of the backlog items he scratching off the list every week that he's got an individual velocity of 7.5 hours per day.

Now based off of this information, we could expect to see a 7.5 hrs/day improvement for the velocity of any team we add Bob to, right? Not so much, let's put Bob on a different team that works very fast but doesn't communicate all that well (a team of cowboys if you will). Suddenly Bob's velocity drops significantly because his team can't help him fill in language specific gaps in his knowledge. What's worse is that Bob's old team saw a dip in the their velocity that's more than Bob's 7.5 hrs/day since they no longer have Bob's amazing mind to help them through some of their more complex problems. This is to say nothing of the velocity of our cowboy team now that they have to "carry" Bob.

What we're seeing is that Bob's velocity is more than just the completed items with his name attached, it's also the way that he contributes to his team and the way that his team contributes to him. In all reality, there's no practical and meaningful way to separate Bob's velocity from the team itself. Even worse, it invites us to act on bad information since measuring individual velocity gives us the illusion of empirical data.

Point Velocity is absolute: Story Points and I don't see eye to eye but we understand one another and I think they can be used effectively in a lot of places (I just don't feel like they're a requirement for doing good Scrum). One thing that always makes me nervous though is when I see multiple teams working on a single product backlog and sharing point values.

Here's the thing, a story point is not an absolute value. When used correctly, a story point doesn't equate to time and it's value is unique to the team that created it. This means that Team A may look at a story and determine that it's value is 5 story points and Team B may look at that story and label it as 8 story points. This might be because Team A is more familiar with the type of work for that story or maybe they just view points on a different scale, it doesn't make their estimate wrong and it also doesn't make the other team's estimate wrong; just the opposite, it makes that team's estimate more accurate since they created it, it makes the estimate relative to the team doing the work.

None of this is really a problem for the estimate's main purpose which is helping the team establish the correct number of stories to forecast for the next sprint based off of their previous velocity. The problem is when I start combining the velocity of Team A with the velocity of Team B for an overall sprint velocity, since the two team's estimates don't always mean the same thing I'm essentially adding apples to oranges, assuming they're the same price and heading to the checkout counter. Compounding this problem is that this behavior invites stakeholders to compare velocities and make value judgements where they may not be warranted (Team B is finishing twice as many story points as Team A which means Team A must be slacking off), this can lead to estimate inflation (which make the estimate essentially worthless) or lower quality work in order to deliver more points than the other team.

Now an absolute estimation method will fare better under this scenario but it's got it's own problems. It's up to you to decide where to compromise with your estimates but if you decide to use points just keep in mind that your team velocities, while useful by themselves, shouldn't be combined.

I could go on with other velocity pitfalls but these are the most common that I see and this post is already getting a little long in the tooth. If you'll direct your eyes to the top of the page you'll notice that I'm putting on another Scrum webinar this Thursday at 11am PST. I'd be tickled pink to see you there, admission is $49 and you can find all the details by visiting the link above.

(Update: The Scrum Webinar went very well and I appreciate the great group of people that attended! I will inform everyone when we schedule the next one.)