How long is a piece of string? Software Estimation
Product Owner “So when can you deliver the new feature?”
Development Manager “The team have looked at the high level plan and have done some T-shirt estimates and based on that we are looking at between 6 and 15 months”
PO “That’s nonsense. I can’t work with that. I need to tell marketing a release date. When can you give me accurate estimates?
DM “After we have delivered it!”
Probably one of my most challenging jobs as a development manager is the communication and discussion with business stakeholders of software estimates and easily the most arguments I have had have been because of this task.
We’ve all been there haven’t we? The company want to release a new feature. They have some idea of what they want and they have a client who is desperate for it and will pay for it! Yippee! So, (often after the ink has dried on the contract), the development team is asked to estimate what effort is needed. Sometimes it’s a list of use cases (if you are lucky) or just a paragraph of what needs to be done. The software team are asked to do it in the next week “so we can get some more resources if we need.” Panic ensues. The team get together but spend most of the time saying their is not enough information to do the estimates. “Don’t worry just do the best you can”. Under pressure the end result the team come up with is an estimate of 6 months. “Great” says the CTO, “we’ll give you 2 extra people and you should be able to do it in 4 months”. Before you know it, a release date of 31st Dec is spoken of all over the company. Then the work starts. unsurprisingly it’s more complicated and takes longer. You go back to the product manager and say its going to take more like 9 months. Too bad — “you told us it would be ready by 31st Dec”. “b-b-but, it was an estimate….” The team work end up working crazy overtime, holidays are cancelled, corners cut and they manage to get something out resembling what was wanted, but only at 11pm on 31st Dec and it hasn’t really been tested except to see if a few pages worked.”
“131% people Exaggerate”
It’s easy to see what happens next time. Software teams inflate estimates for fear that they will be taken as the truth and deadlines will be set based on them (- a couple of weeks, because surely we can shave off some time for efficiency / get them to work harder as a consequence).
Some of the worst culprits I have found in this whole scenario is the Senior Leadership teams within Tech itself, who seem to display a collective amnesia about the complexity of software changes, most comically on software they probably created in the outset and left with swathes of Technical Debt. No doubt it is in part to impress their business counterparts that their teams can deliver it quicker, down to their ‘leadership’. One leader I knew used to boast that at a previous company he worked at he could “get software estimates accurate to within 10% and was going to make that happen here”. The irony of the juxtaposition of the words “estimate” and “accurate” escaped him.
So what’s the solution? Storypointing, MVPs, Spikes and an iterative approach all help move towards this goal but for me the single most important element is trust between the software team and the product owner. On the product owner that they won’t make promises to the rest of the business based on estimates and on the software team that they will give honest assessments of work involved and will do everything they can to understand the commercial drivers behind getting a feature into production and work accordingly.
When this works it is a powerful thing. I’ve seen it and its a million times more effective than the ‘them’ and ‘us’ attitudes that exist in some places and that do nobody any good.
