Key 18 - Team Velocity: Michigan Agile Philosophy (MAP) Project Key

18. Team Velocity

This is it! If you have made it through all 18 of the project keys with me, thanks for sticking it out. I hope there have been a few nuggets that have intrigued you, taught you something, and possibly even entertained you a bit. As we pull into the barn I want to share one last key…Team Velocity.

Velocity is one of those topics that managers usually salivate over. It’s a metric. It’s measurable. It can be used as a giant stick to wallop a poor unsuspecting employee. Yes. More sticks. After all, it’s no fun if you can’t beat up on an employee over their performance on occasion right? Well, I hope you can see the silliness here.

The fact is, Velocity came about for a very different reason. The idea is that Velocity is just a measure of the amount of work a team gets done per iteration. If you are using story points, it’s the number of points completed in the iteration. If you are making all stories the same size, your Velocity is the number of stories completed that iteration. You calculate your Velocity and use that number to plan your teams next iteration of work. If your Velocity is 6 points, you should plan about 6 points worth of work the next iteration.

In practice, Velocity is an INTERNAL measurement. That means it’s really only for the team to know. Managers shouldn’t need to know a team’s Velocity and frankly they shouldn’t care. If the team feels they have over committed it’s their responsibility to solve the problem. If they under commit, they will have to decide if they are going to pull something else into the iteration. The team should be working with the Product Owner to set expectations and they should be transparent about the work they are doing and that they are planning.

How do you calculate your velocity? There are a few ways that work pretty well. Most of the time Velocity is an average of the amount of points completed for a certain number of weeks. If you have done 30 points in the last 5 weeks, your velocity is 6 points per iteration. Therefore you should probably plan around 6 points for the next iteration. In that case we’re averaging 5 weeks. Some people like to average all the weeks of the project. I like to average the last 3–4 iterations. Some groups just use something called “yesterday’s weather.” Yesterday’s Weather looks at what you did the previous week and uses that as the number of points you will plan for the next iteration.

If you remember the blogs on Estimated End Date and Actual End Date you’ll remember we used Burn Up Charts. To calculate those we are using the team’s Velocity to make predictions about when they will get to MVP or finish the project.

My blog writing velocity was about 2 per week. They didn’t always come out that frequently, but that was the writing tempo. At that rate I could tell with pretty good certainty that it was going to take 9 weeks to get them all written. When I started I did 3 some weeks, 1 other weeks, but over time my progress smoothed out to about 2. Projects tend to work like that as well. As teams get better at estimating as a group and as they understand the work better, the Velocity starts to average out as well. They begin to commit to about the right amount of work and they get to a beautiful place called Steady State. That means, no 80 hour work weeks. They focus on their work, get it done and move on in a consistent manner.

Like many things, it’s a place to start. If the team gets good at delivering, the need for Velocity may start to fade or evolve slightly.

That’s it! All 18 project keys served up for you in a nice Agile stew. Again, I hope these were helpful and I hope they will spark discussion. Remember, Agile is about your mindset. These keys are just to help us think about specific areas where we often stumble. Hopefully when those stumbles occur we will take the time to learn and improve.