Scrum is just the tip of the iceberg of course. It’s just particularly frustratingly that a supposedly “agile” methodology is advocating such bad practice, which I’m sure is a sop to all the organisations who want to hang on to the idea we can be predictable so they (SA) can sell more courses.

In an iterative, reflective process you’d never get to a position where you say “we’re 6 months late because there were a few unseen problems”. As soon as you see the actuals starting to diverge from the estimates you have useful data you can act upon, long before the point where you have to start apologising.

The clue is in the name: they’re estimates not promises or guarantees. They say “all things being equal, this is roughly what we think”. If things don’t turn out to be equal, they give a useful mechanism for understand the impact of what’s changed. If things do pan out to be equal they provide valuable information for course-correction and individual improvement, not to mention, as Dan describes, discussion and debate about what is being delivered.

But the argument isn’t about Scrum/CSM courses but about whether estimation has a place in software development. I’ve seen this argument rage over a number of topics over the years (specifically: patterns, tools, TDD/refactoring, full-blown XP, different languages, etc. and so on) and I’m afraid that the position “its dangerous because most people don’t get it and get burned by doing it wrong” isn’t one I can support.

Here’s what I know about estimation:

* Most people don’t get it and can’t do it
* I, and other people I know (including you it turns out ;)), do get it and can do it
* Practice leads to improvement, and improvement brings benefits
* Some people will never get it and should steer clear

I could have said exactly the same about XP in 1997. But rather than focusing on the last group of people all the early adopters of XP focussed on improving themselves and helping others improve. Mainstream adoption was never achieved – and possibly never could or should have been – but I believe there was an overall improvement in the state of software practice. If some people got burned by implementing XP naively or tried XP and failed because they didn’t really get it, I’m very sorry for them but that has no bearing on how I feel about XP or, in this case estimation.

But now, as in 1997, I’m happy to say ‘it works for me’ and if the conclusion is I’m uniquely brilliant at this stuff and just because I can do it doesn’t mean any one else can, what can I say? Apart from that I know I’m not uniquely brilliant and if I can make it work for me, there are many people who could make it work as well if not better.

I haven’t. What does it have to say on the subject?

Yes thank you for reminding me about that piece of work and how valuable the estimation we did was. However the important information we got from the exercise was not /when/ the work would be done, but that it was going to take a lot more effort and time than people thought. In that circumstance (and some similar since) it’s proved very useful indeed, but that’s a very different thing to estimating for the purpose of knowing when something will be done.

I’m not saying all estimation is bad, but the way it’s used in the majority of organisation’s certainly is and I strongly believe it’s one of the main causes for software project failure.

I don’t think it’s a symptom of a deeper issue – I think it’s core to why IT depts. tends to have such poor relationships with their organisations. It’s the continued failure of software projects to be delivered “on time and on budget” which has lead to the widely held cynicism around software delivery. In pretty much every circumstance which reinforces this perception it will be because estimates were provided, deadlines and budgets were set accordingly and inevitably they were missed, generally by a factor.

By providing long range estimates we are perpetuating the myth that we can have certainty in software development when we know that’s not true. It might be a more painful start to a project to resist the urge for that certainty and push alternative ways of managing risk, but considering what happens now that’s got to be preferable.

I can’t argue with your experiences and if you’ve managed to make estimation work for you that’s only a good thing, however I don’t think that’s enough to convince me that, for most people and in most ways it’s used, estimation is working or that we can get around some pretty fundamental universal laws of nature.

One thing you mention is how through practice you can get better at estimation, which is no doubt true, especially if you’re aware of cognitive bias and so on. However the difference between estimation and a skill like TDD is the consequences are much worse if you get it wrong. The skill of estimating is not only in improving the reliability of your estimates, but how you manage their use within the business. In many places that is something which is outside of your control, especially if you are “just” a lowly developer in a large bureaucratic organisation.

Paul, you are no doubt an extremely experienced practitioner who, regardless of the organisation you’ve worked with has managed to make estimation work for you. I have to admit I have too, but certainly not in the way that most people are using it or most people who advocate estimation talk about it. The main gateway in to Agile remains Scrum and the second course people tend to go on after CSM is Scrum Estimating and Planning. Having been on one of these courses myself I can attest to the fact what they’re teaching is downright harmful – that somehow through the magic power of story points, velocity and burn down charts you can have some confidence, over long periods of time, of when something will be “done”. People are naively taking this back to their workplaces, brimming with confidence in the new world of Agile and getting themselves in really awful situations. That’s why I think it’s just super harmful to be advocating long range estimating and especially that Agile has some answer to this.

And that’s just “Agile” practitioners who still represent a minority of the people making software. Outside that sphere it’s just an abomination.

I’m in part agreement with Rob about the misuse of estimates and how that is harmful. Where I differ though is that I don’t think that it’s the root of the problem, instead a symptom of a deeper problem, the typically poor relationship between IT vendors and their customers.

What is the point of a number that *may* be right 68% (or even 95%) or of the time, and often will be wildly outside that range of one or two standard deviations?

There are lots of pieces of work in a software project. Lots of potential “outliers”. What do you say to the customer when you have a few pieces of work out of 30 or 50 that you didn’t estimate correctly and things run a month, two months or 6 months late? “Oh we were just unlucky”, or “Oh there were a few unseen problems”?.

What you tell your clients and how you monetize the project is not something I have an answer to, it differs from company to company and client to client, but long range forward estimation is certainly not something I think is valuable.