| This is a great list. My thoughts on two of the points: > The biggest value in estimating isn’t the estimate but to check if there is common understanding. Wholeheartedly agree. The amount of extra detail I've captured out from the team, with wildly varying estimates on a particular work item, is astounding. It forces the team to articulate assumptions and dilineate between in-scope and out-of-scope details. This works especially well when stakeholders are in the same session, asking for why a button cannot be made blue in under 5 minutes. > Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that. Not sure. Perhaps breaking down tasks has a negligible effect on estimation accuracy. Maybe this is true for simple environments without complex dependencies across teams. But breaking down tasks provides (1) some certainty that you know a thing is achievable, (2) gives you a strong idea of what can be started immediately, and what can be run in parallel, and (3) hidden dependencies on other teams. This in turn leads to a better estimation. I have observed many failures when management assign a vaguely specified task (contrived example: "rewrite persistence layer to talk to new database") to a developer, that should really have been broken down into smaller tasks. |
The more general rule is to force people to put numbers on things.
- Not "will this be expensive?" but "how many dollars do you think this would cost?"
- Not "is this a big project?" but "how many calendar days will this take?"
- Not "will we need a small amount of paint only?" but "how many litres of paint should we buy?"
People very easily come to false agreement over vague terms and goals, but when the numbers come out it's revealed how different their opinions really are, and that's when the useful discussion about assumptions and theory start.