Team Velocity

In Agile Development, you have a concept of Story Pointing and Team Velocity. Most people hate coming up with time estimates. If it is in hours, it is too specific, and then you feel under pressure to meet the exact timescales. With bigger work, it’s quite hard to measure things in days. The idea of Story Points is that you can just gauge items in comparison with each other, so you think about your smallest piece of work, then benchmark all other work against it.

Although teams may roughly have the same scale, and you could roughly map Points to days; the scale only truly makes sense within that team. So 5 points for Team Badger, may be a different size to 5 points by Team Snake.

The amount of Story Points you complete in a “Sprint” (often a 2 week period), becomes your Velocity. Well, the Velocity really makes sense as a moving average across multiple sprints, because in Sprint 1 you may go through 20 points, but Sprint 2 may achieve 35 points. If you analyse it, it may be because people understand the project and are working better together, so improved in the subsequent weeks.

We had a meeting today. One of the questions was

“What’s your team’s velocity? If you don’t have one – then pick a suitable number“.

A) What are we doing with these numbers? Comparing them between the 3 teams? It’s nonsensical.

B) It turns out people haven’t been working in this Agile style anyway, and haven’t Story Pointed their work. But if Velocity is a sum of completed work that has been estimated, how can you estimate how many points you have completed by estimating what you think your estimations would be?

I’m sure managers are getting dumber.