Firstly I asked the audience why we estimate?
- Predictability
- To be able to choose between options
- Planning
- So we can manage budgets
- To justify development
- Manage expectations
- Learn more about the problem
- Synchronise with other projects
- Get a cost benefit ratio
- Prioritisation
- Customers like to know when it’ll be ready
I then did a short presentation (slides below) explaining why we’re no good at estimating.
Finally we had a group discussion where we discussed my findings and what we can do. Here’s the output:
People often care more about the deadline as they only use 5% of the features
We need to create a better contract with the customer
When we need to synchronise with other projects what choice do we have?
We rarely measure by what we’ve achieved.
- Should be more like “we need this much business value for this much money”
Trust doesn’t exist – contracts are defense against the risk
That’s life! E.G. 2012 Olympics site build – people need to come together on a deadline
Agile enables us to react and focus on what’s important – is it scope? is it cost? is it deadline?
Also, iterative development means at least we deliver every two weeks to at least have something.
Measurement should be based on what’s been done.
However, estimation is used to measure productivity – we need better forms of measurement.
Estimation is not risk management but it’s what it’s used for.
Should the customer estimate value?
The closer you get to the end of a project the greater the pressure to estimate accurately.
Also is the impact of pressure from customer to estimate more accurately.
When integrating with 3rd parties need to estimate.
Need to recognise risk when estimating.
- Sponsors need to understand risk.
Time/duration of estimate = ^risk.
It’s about how we manage the estimate not the way we estimate where the answer lies.
- Managing risk/quantifying risk
If customers are more aware of risk they’ll make better decisions.
A good model would be to recognise the risk in the contract e.g.
x% risk = x cost
xx% risk = xx cost
Resources
Slides
Links
The Black Swan: The Impact of the Highly Improbable
Oliver Burkeman on why everything takes longer than you think
Overcoming Bias: Planning Fallacy
Dept. of Helth Guidelines for Optimism Bias
Cone of Uncertainty Controversy
Predicting Velocity When Team Membership Or Size Changes Frequently | Mike Cohn’s Blog
Use Risk Management to Make Solid Commitments
There’s a lot more on my delicious bookmarks tagged for estimation
November 25th, 2008 at 8:04 pm
My organization is currently looking into software estimation (after an audit said we didn’t have an effective process in place). Your posts about the non-value of estimates are great. Poking around the web it seems like a lot of people feel estimates are less than valuable. I also find a lot of information about how to do agile estimates during release and iteration planning (like Mike Cohn’s book). But I have yet to see anyone describe a good process for coming up with an “estimate” which can be given to upper management during initial budget planning exercises, or really any time before the development gets underway.
BTW: the links to your slides seem to be broken.
November 27th, 2008 at 9:28 am
slides links fixed, sorry Geoff and thanks for your comment
December 14th, 2008 at 4:11 pm
[...] followed the same format as the previous time I ran it so you can go there to find the slides [...]
April 7th, 2009 at 4:10 pm
[...] And here is the output transcribed (you can view output from the other times I’ve ran it here and here: [...]