Now that we understand the concept of estimation, we need to talk about how this “credit system” applies to our velocity.

When your team goes through estimation, each feature needs to be assigned some “credit” so that you can then use that amount for projection and release management. The issue is what you use as your “credit”. A common idea would be to use “work time” as the credit. There are a couple problems with work time, though. First, each team member’s work time is different, because their productivity levels are different. This means that when they estimate they would have to think about how much time it would take for them to complete the feature, which is always going to be different with the other members, so they won’t be able to come to a consensus. They have to come to a consensus when estimating each feature, so work time won’t work.

Since we know we can’t use a metric that varies on each team member, we need to pick something that is relative and allows the team to vote as a whole. That’s why my teams use a concept of “points”. We use a modified version of the Fibonacci sequence (i.e. 0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, infinity). We don’t go past 34 usually because after that the risk that the estimation is significantly wrong is too high. That brings us to another point worth mentioning.

When you are estimating how long it takes to do something, it’s better to try to keep your features small. The same is true for road trip planning. If I am planning a trip just outside of Atlanta (where I live), then it’s a lot easier for me to figure out how long it’ll take me to get there. If I’m just going up the road, then I might even be able to get my travel time figured out down to five minutes. The farther away I go, the harder it is to accurately estimate. With a trip as far  as Orlando, I know I’m only accurate within an hour or two. That’s a much larger margin of error than five minutes!

The same is true in estimation and your credits. If you assign a feature a large amount of credits, then the margin of error is much larger for that feature. That’s also the reason why we don’t just let the team pick any number they want. If a team member is having trouble between an 8 and a 13, they have to pick one or the other, they can’t say “I really want to choose 10”. The point here is that there’s a margin of error because of the uncertainty, and the Fibonacci sequence shows that uncertainty in the estimations very well.

Once you’ve identified your credit system, then you can use that system to determine your team’s velocity. And that brings us to our next topic:

Determining your team’s velocity