We like numbers because of their symbolic simplicity. In other words, we get them. They give us certainty, and therefore confidence.
Which sounds more trustworthy: “It will take 5 months” or “It will take between 4 to 6 months”?
The first one sounds more confident, and therefore we trust it more. After all, why don’t you give me a simple number, if you’re not really sure about what you’re doing?
Of course, if you knew where the numbers came from, you might not be that confident.
Simple and Wrong
In our story, the 5 month estimation was not the first one given. The team deliberated and considered, and decided that in order to deliver a working, tested feature, they would need 8 months.
“But our competitors can do it in 4 months.” shouted the manager.
“Well. maybe they can. Or maybe, they will do it in half the time, with half the quality” said the team.
“It doesn’t matter, because they will get the contract!” the manager got angrier.
The team had nothing to say. They left the room for half an hour. Then the team-lead came back and said very softly: “We’ll do it in 5 months”.
Wastimates
The project plan said 5 months. No one remembered the elaborate discussion that went down the toilet.
Estimates are requested for making decisions. In our story, the decision was to overrule them. There’s not really isn’t a way of knowing who was right. Many companies thrived by having a crappy v1 out, and then fixing things in v2. They might not have gotten to v2 if they had done v1 “properly”. Then again, it might be that they bled talent, because the developers were unhappy, or not willing to sacrifice quality. Who knows.
The point is: the effort put into estimation should be small enough to provide the numbers to management. If the team had reached the “8 months” answer after 1/2 day, rather than after dissecting the project dependencies up front for 2 weeks, they would have more time to work on the actual project.
By the way, they might not get the go ahead. And they would work 2 weeks more on other projects. That’s good too.
Don’t waste time getting to good enough estimates. Estimate and move on to real work.
PS: Based on a true story.
| Reference: | How To Waste Estimations from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
Story of my life. I lose count of the amount of times I’ve been asked how long it would take me to do something and then watch the time get wittled away until its less than half the original estimate. Worse yet, the estimates I’m required to give are based on loose, vague and often half defined functional requirements in the first place.