Estimating in Points Seems a Bit Stupid!
by Kelly Waters
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.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by MissTurner
28 October 2008 01:46
You make an interesting Point (pardon the pun!).
Having enough history to have an accurate feel for a development teams velocity makes a big difference to the ability to plan an appropriate amount of work in an iteration.
This can't be fast-tracked; the capability of a team is only realised over time and with experience.
At Ergo (http://www.ergoconsulting.com.au), as a software house developing solutions for corporate clients one of the challenges is to be able to accurately plan a project based on an unknown velocity as we may not have worked for that client before and the exact makeup of the development team might be different from project to project. However this has a direct impact on the commercial arrangements put in place for a project; A client will naturally want to know how much it will cost and how long it will take.
I'd be interested in other peoples experince's in this regard.
I would also be interested in people's experiences in 'moving' a team from estimating in 'days' to estimating in points and how they went about it.
21 April 2009 15:29
We are in the process of starting the story points system after several iterations of using the ideal hours.
I should say using ideal hours have its own benefit as well:
1- You can have the initial team capacity based on their presence time two weeks in advance.
2- You can calculate estimate deviations on a daily basis and have a very good idea where your team is standing on mid-iteration.
3- You can keep track od actual team capacity on a daily basis and have an idea about why the team did or did not burn the initial work volume.
4- You can easily monitor the team's velocity on a daily basis and have a good idea about the trend before the iteration ends.
5- It is easy to find who is dragging their legs and who is championing the burn down and provide help to those who need it.
None of them are these are possible when using Story Points which makes it quite difficult to monitor anything before the end of the iteration and even then makes it quite difficult to do a root-cause analysis on any deviation.
17 June 2010 09:32
@Anonymous. Once you know your velocity you will be able to track all those things whatever method you use to estimate.
You'll know you can get 3.5 points done in a day and use that value in your points 1-5.
As for point 6 you can use your stand ups to ensure everyone is working as productive as they can. You should need to be micro-managing quite so much... have a cup of tea instead.