rob bowley

I ran my session on estimation again at XPDay 2008 last week. I’ve come up with a decent title for it now: “Dealing with the Estimation Fallacy”.

It followed the same format as the previous time I ran it so you can go there to find the slides etc.

Here’s the output from the discussion. I’m running this session again at SPA 2009 and after that I will collate the output from all three into something coherent and useful:

How do you keep the context stable?
The problem is managing the context. If the business says you need to do it sooner that changes the context.
What about if the business doesn’t have the full context? What about issues you don’t know about?
Why are we different to any other type of organisation?
It’s too difficult to estimate more than 2 months ahead
Familiar work is easy to estimate, the unknown is not (which is mainly what we do)
If we report back to the business regularly they can’t deny hard facts
Manage the risk by working iteratively
It’s quite common for people to start building skyscrapers before the architects finish designing the top

• but their customer’s not going to ask for another 20 floors and more space halfway through

We need to help the customer understand what they need
People need to know whether it’s a viable business case
Projects are never agile if you have requirements up front (fine if nothing changes though)
You should only commit to work three months ahead
“2 years” for a software project is too long – will not be competitive
Movies spend a long time in development, then they get the budget and the scope gets cut to fit. But, they are more predictable than software.
Too much money (e.g. banks) will never produce good software – scope to big.
Are big estimates/commitments ever believed by anyone? Often they’re only used to make projects viable
IT departments are not pushing back enough – should never suggest you can plan more than 3 months in advance
2 types of estimation:

1. The real business of estimation (e.g. stories, iteration scope, tasks ect)
2. The game of estimating within the business context

Agile projects are rarely ever really agile as they’re operating withing the context of the business/traditional practices.