Estimates for software projects only need to be sufficiently accurate to serve a purpose, but if that purpose isn’t clear then producing the estimate can be quite stressful.

Over on the emergn Value, Flow, Quality blog Chris Berridge says

If the estimate information you are producing isn’t vital for making a decision, then take a good hard look as to whether you need it. Some of the teams I have worked with have stopped some kinds of estimates as these estimates were not changing the decision.

But often it’s not a binary choice of do we/don’t we need the estimate. Instead it can be a case of “we need to know if it’s likely to be more than…”. In this case producing the estimate is about determining where the project sits in relation to that threshold. That means estimation is still valuable, but accuracy may be more relaxed.

Recently I was involved in what I consider to be a good estimation exercise. The team was asked to estimate a project, we came up with figure, and the stakeholders consequently decided that the project was too big and should drop down the priority list. I regard that as a success because the number was not questioned and it did influence a business decision. But some of the developers involved were unhappy with the exercise because they didn’t know how literally their number would be taken, and felt that what they were producing was going to be turned into a deadline. I’m sympathetic with that perspective: it was a stressful experience despite a positive outcome.

This is a difficult situation to fix, though. We would have had a much less troubling time if the stakeholders had said at the outset what “too big” would have looked like; then we could have estimated only if the project was likely to be bigger or smaller than that figure. But in reality the stakeholders didn’t know what “too big” was, so couldn’t have communicated it. It was more a case of “we’ll know it when we see it”.

In the end someone has to put their cards on the table first, and usually that’s the tech team. The stress can be removed from the situation if, over time, it is demonstrated that those tech estimates are treated as intended — not as promises, but as contributions to informed business decision-making. The stakeholders demonstrate their respect and understanding of the development process, and the development team sees that they are regarded as genuine partners in the business.