Thinking Journeys rather than Estimates
riskfirst.org
riskfirst.org
There are other important places to stop. An important one that planning-eager folks neglect is complexity.
The high-level estimation needs to be light enough that you will redo it, perhaps entirely, if the facts on the ground change. You will need to assign some risk to the plan itself since it will cost some time, energy, money, communication bandwidth, political capital, etc. to change the plan.
How much planning risk depends on a few things, but how much the details of the plan are exposed is an important thing to factor in. If you've signed contracts with 1000 people promising that you will complete step M on exactly the week of April 8 and it will be entirely free, you have made it hard on yourself to change many things in your plan.
I do agree that estimation comes at a cost, but I suspect that tool support could make that go down a lot.
Eliminating risk is awesome though and even that practice is compatible with estimates if thats what your team is doing. Simply asking the question “whats the riskiest part?” prompts some healthy discussion.
Momentum is important and you can lose it by tackling risk too late or too early.
When a new team or project is forming, doing the riskiest thing first can become a self fulfilling prophecy. I suspect that’s a big part of why so many of us get wedged trying to start personal projects or businesses. We go toward the risk too quickly in an effort to save time and then we save loads of it by giving up.
You do want to build toward the risky things, both as a team and individual contributors. Some teams fail to thrive because the senior members continue to take on the bulk of the risk, while new or younger members are forever stuck at mid-level until they quit and join another team.
If you describe estimates as ranges or distributions, a whole world of risk analysis tools open up - PERT, Monte Carlo, etc. More crucially, it allows you to start communicating and managing risk openly with everyone involved, instead of pretending it doesn't exist.
For example, in the summer I got an intern to build an app. It demoed well and people naturally asked when it would be in production.
Working in quite a regulated environment, I knew this wouldn’t be as simple as just firing up a couple of EC2 instances, so I said a couple of months to get it live on the ‘internal cloud’.
It still isn’t live. Maybe someone more experienced than me could have predicted that.
What you couldn't do well is say when particular stories would be completed, or what the 80%/90% etc times would be. You'd need to use something more sophisticated.
Alchemy: the medieval forerunner of chemistry, concerned with the transmutation of matter, in particular with attempts to convert base metals into gold or find a universal elixir.