Here they are, in alphabetical order, because none is any better than any other:
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.
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?
Scrum Master: But we only managed 5 last week! How many do you really think we can manage?
Scrum Master: (facepalm)
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?
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.
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.”
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.
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.
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.
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.”
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.
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.
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.
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.
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.
PM: How many story points can you manage this week?
PM: That’s not good enough. I need you to do 12. How many can you manage this week?
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.
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.