Dan North’s talk on “the Fallacy of Effectiveness” prompts me to put down the many estimation anti-patterns I’ve encountered. It also reminds me of his blog post on the Perils of Estimation.
Here they are, in alphabetical order, because none is any better than any other:
Budget-driven Estimation
Whatever estimate you come up with will be enlarged by the customer so that he can spend the rest of this year’s budget, otherwise he won’t get it again next year.
Catch-up Estimation
Scrum Master: We have 30 points of work still to do, and only 2 more sprints to do it in. How many points can we manage in a sprint?
Team: 15!
Scrum Master: But we only managed 5 last week! How many do you really think we can manage?
Team: 15!
Scrum Master: (facepalm)
Comedy-driven Estimation
As told to me by Dan from a talk he saw – if you know who it was please let me know so I can credit:
Presenter: How tall am I?
Crowd:5’8″! 5’9″! 2 metres!
Presenter: Go on, you can manage more than that. How tall am I?
Crowd: 6’2″?
Presenter: Come on! You can do better than that! HOW TALL AM I?
Crowd: (Giggles nervously.)
Presenter: Just because a project manager tells you you can do more, it doesn’t make it true.
Done-driven Estimation
A symptom of a pressured team, this method of estimating allows a pair of developers to get the story out of their stream as quickly as possible by eliminating time spent on tedious things like refactoring to make the code maintainable, deployment, manual testing, etc. Symptoms include the oft-quoted “Works on my machine.”
Done-done-driven Estimation
A good team knows, of course, that the code counts for nothing until it’s out there in production, doing the thing it was built to do. Estimates are given with this in mind, but without the help of anyone involved in production deployment, systems integration, performance testing, UAT, etc., because they’re in different teams.
Fractal Estimation
After the scope of the project has been constructed, some stories may be considered too large to fit into an iteration, so the team decide to split them into the smallest possible deliverable slices, re-estimating each slice. Of course, this is a bit like measuring the coast of Britain. The epic which was 13 points at project inception becomes 16 points of features, and 23 points of stories by the time it’s done in the sprints. Analysts wonder where this extra scope came from, while advocates of burn-down charts tuck the growing scope away somewhere where it won’t be noticed.
Goat Estimation
Asking a goat can help when you know it doesn’t really matter what you say, you’ll probably end up doing target-driven estimation anyway.
Job-driven Estimation
As practiced by residential consultancies on Time and Expenses, contract Project Managers and anyone else with an interest in seeing the project go on as long as possible.
M25 driven Estimation
“Yes, I know it took me 3 hours to get around London yesterday, but that was because there was a traffic jam on the M25. Today will be much quicker.”
Pareto Estimation
Often used by teams which have work still left over at the end of an iteration and desperately want to include the incomplete work in their velocity. Unfortunately the Pareto principle, applied to tasks, suggests that 20% of any task will take 80% of the time. Let’s hope the 20%’s not the bit that got left till last.
Post-mortem Estimation
The team chooses estimates that will allow them to avoid the post-mortem inflicted by the project manager when they missed the deadlines last time.
Promise-driven Estimation
Developer: “These estimates… they’re just estimates, right?”
PM: “Don’t let the business hear you say that!”
Like Scrum’s sprint commitments, but used for release or project planning, this estimation method often leads to three-week long project planning meetings before the project starts. Frequently occurs as a result of fixed-price contracts with first-time suppliers. Also the second time. And the third.
Star-Trek Estimation
Geordi La Forge: I told the captain I’d have this analysis done in an hour.
Scotty: How long would it really take?
Geordi La Forge: An hour!
Scotty: Oh. You didn’t tell him how long it would REALLY take, did you?
Geordi La Forge: Of course I did.
Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.
Student Estimation
If an estimate is chosen wisely, 50% of measurements will fall under the estimate, and 50% will fall over the estimates. Strangely, nothing ever gets handed in early, no matter how inflated the estimate is.
Target Estimation
PM: How many story points can you manage this week?
Team: 10.
PM: That’s not good enough. I need you to do 12. How many can you manage this week?
Team: 12.
Velocity-driven Estimation
Once a target velocity has been established – sometimes by the team itself – the team members will find a reason as to why the work they’re capable of doing does actually add up to 12 story points. Often applied in conjunction with Fractal Estimation.
Zero-outlier Estimation
If being wrong is uncomfortable, a team will wait for the most experienced developer to “throw” their estimate first before following suit. Planning poker fixes the symptoms, but not the problem.
Liz Keogh, lunivore 
Love the list! I have one more to add: “False Security Blanket Estimation”
This occurs when a team hits their estimated sprint commitment. But a closer examination of actual development time shows that many of the 2 hour tasks took 8 hours and some of the 8 hour tasks took 2 hours, making it a wash. But teams like this will pat themselves on the back for doing a good job of estimating.
When asked for an estimation you always need to give a number, no matter what.
I love these and have come across many of these at some stage or another. I have a couple to add as well…
False Sense of Accuracy Estimation. When an estimate is presented as a single figure with no range of values, best/worst/likely scenarios or probability distribution associated with it.
False Sense of Precision Estimation. When an estimate for a year of work is presented down to the day, an estimate for a month of work down to the hour, etc.
I love very much these type of posts. Because, they’re rich in talk but does not provide any useful solutions to the problems at hand. Please, don’t understand me wrong, I do not target this article.
Estimation is a needed practice from the business perspective. Or what else do we need? I personally know that many programmers are lazy and are the people of gaming the systems. Not only the place they’re in makes them so. They’re innately so. Most of them are the people of humiliation. Humiliating with most of the things around them. Yes, people want to do good job. And, programmers too. But, in their way, and when they want it to. I don’t know where I am trying to reach with these thoughts.
Thanks for reading.
Hi Inanc,
Check the article I linked at the top for a different way of doing things: http://dannorth.net/2009/07/the-perils-of-estimation
There’s one solution. Lean / Kanban’s SLAs are another, though difficult to introduce in an environment without trust.
Pingback: How Can Software Development Avoid The Need For A Hero? | Regular Geek
Extremely funny. And sadly very realistic too.
Pingback: LaSSar2000 Blog » Blog Archive » Liz Keoghs blog » Estimation anti-patterns
Pingback: QuickLinks for February 2011 | (Agile) Testing
We-all-know-it’s-hours-estimation
When you estimate in “weights” but everyone secretly multiplies the figure with a constant amount of hours.
You should definitely add Drunken Estimation to this list.
Then again, it might be too serious:-)
Love this list. Still as much as two years ago…
Wonder if this is one of the pieces you come back to every few years, like the MythicalManMonth.
Thanks!
Olaf
Very funny. Target Estimation is the one I’ve encountered the most
WRT Student Estimation, my experience is that, in our efforts to please managers/teammates/whoever, we developers tend to give our Best Case or Near Best Case Estimate as The Estimate. We hope to always be performing at our peak with no interruptions or problems. This is very much related to False Sense of Accuracy Estimation mentioned by Andy Marks.
You forget the double act.
him: Exactly how many days will it take to develop all this?
me: 1327 days.
him: You are kidding?
me: You started it.
Take your actual estimate. Multiply by 2. Go up one unit of time.
So if you think 2 hours, say four days. Can someone give me a name
for this?
Pingback: Sizing, Estimation and Forecasting | radtac
Pingback: The Estimates in #NoEstimates | Liz Keogh, lunivore