Joe Arnold's Blog

In software, one thing is certain — estimates never match reality. Teams build predictable schedules by creating buffers. There are two strategies to do this: 1) by forecasting how much buffer the team needs 2) by computing buffer based on past performance.

Velocity is a way compute how much real time it takes to complete estimated time.

So if I say something will take me 4 hours to build and it takes me two days to complete, my velocity would be 2h/day. That’s useful for future planning because the team knows my capacity (2hr x 5days = 10 estimated hours / week).

A velocity measurement doesn’t say how hard I worked or how much time I spent on the task. It’s merely a calibration tool for effective planning.

My 4 hour estimate (that took two days) from the above example might of seemed awfully optimistic. But that’s not how to see it. I could of ran into an unforeseen complexity, faced an unusually large meeting load, or could have been bogged down with operational issues. Or it might be true, I might just be an optimistic estimator, but with velocity that’s okay. It all averages out.

Teams will also come together to estimate entire features this way. They might estimate how long the feature will take in days. But again, estimated time never equals actual calendar time. So if it takes the team estimates a feature to take 1 day, and it ends up taking 2 days to complete, their velocity would be 2.5 estimated days / week.

Here’s where it gets tricky and controversial…

To get better at estimating when using velocity means getting more precise rather than accurate.

Teams who are good at estimating with velocity will normalize on an inaccurate, but precise value, rather than try to get more accurate. The consequence is that each team (or person) will have their own, unique velocity. Some teams will estimate conservatively and others will estimate optimistically. It is meaningless to compare from team to team or location to location. It just doesn’t make sense. In fact, the moment you start judging teams on ‘improving’ their velocity, their estimates just become more conservative. (Thereby increasing their velocity.)

Some teams have a difficult time using velocity. This is because when a team settles down on a velocity, they question themselves (or get questioned) if it’s not 8 hours of estimated work a day. “How come you’re only planning for 5 hours of work a day! What’s wrong?” (One of the most productive teams I’ve worked with averaged 2hr estimated / person / day!)

Use velocity, but keep in mind that a team’s velocity can’t be compared with other teams. So keep the velocity numbers within the team. If you must report your estimates externally, either take the time to explain velocity or normalize your estimates into real time. Better yet, translate your estimates into dollar (or rupee) values (talk with your finance person to work out some numbers).

Tags: Agile, planning, velocity, XP