A while ago I blogged about “What’s the Point in estimating?“.
To be honest, I didn’t understand the concept of estimating in Points when we first adopted agile. Actually, I thought it sounded a bit stupid!
But I get it now, and it makes a lot of sense.
I would add to my original blog post now, that developers are more inclined to give a relative estimate in points based on minimal information about a feature, whereas to estimate in days implies precision and can be a barrier to getting someone to commit to how big it is.
But the key thing about estimating in points is actually about how a team’s estimating is self-correcting. Even if they are bad at it.
Let me give you some examples…
Let’s say your team estimates they can complete 100 Points in a Sprint. Actually, they over-estimated because they’re naturally cautious, and in practice you find they deliver 150 Points. Great news! Next Sprint you bring 150 Points into Sprint Planning. Imagine that in hours. Imagine your team’s response when you say they tend to be cautious, so your going to plan on them doing 7.5 days a week! Not going to go down too well I suspect.
Now look at it the other way round. The team again estimates 100 Points but actually achieves only 50. In this case the team is over-optimistic and let’s say they consistently under-estimate, causing late delivery or delivery of reduced scope. You adjust accordingly and bring only 50 Points into the Sprint, because you know that’s what they can typically achieve. They start to deliver on time and the business unit or customer is happy because you’re meeting expectations. Now imagine this in days. You tell the customer or business you’re only going to plan on the team doing 2.5 days a week because you know they tend to under-estimate, or you use negative statements like you’re planning on 50% productivity or utilisation. Not going to go down well either!
Using Points makes the unit of estimation abstract, which makes it easier to commit to, and easier to adjust your commitments to.
Of course on a project, making this adjustment could mean you won’t be able to deliver everything you planned to in the original timescales. Agile – and estimating in Points – doesn’t solve that. But it will highlight it early, while there’s still time to do something about it.
And the self-correcting nature of estimating in points will help you to meet expectations more consistently.
Kelly.