posted 18 years ago
It's useful to estimate use cases or any sized tasks relative to each other. You don't need any idea how long they'll really take to do this, but you need to feel fairly sure that a 4 is twice as big as a 2, or these five tasks are all the same.
Then you can take a guess at how long some of them will take. You might decide an "4" takes one person a week.
You'll probably be asked to estimate the scope and staff and time for the entire project at this point. Such estimates are always rough unless you have solid experience with the architecture, the team, the customer, the domain and every other variable in the world. Which isn't often, is it.
Then pick some tasks to work on. I like Scott's link a lot where he shows planning the near range tasks in detail, and just blocking out big bunches of them in the future.
As you run a few tasks, validate that "4 equals a week" idea. If it turns out you can do 6 in a week, you're in great shape! If it turns out you can only do 2 in a week, you just learned this in a matter of days and you can adjust the plan accordingly.
BTW: I like one definition of risk as "uncertainty in the plan". If you don't know your variables or even one or two use cases well enough to estimate, that's a risk! Make sure everyone is aware of the uncertainty and has some idea what THEY will do if things are not as predicted. Otherwise we know exactly what YOU will do: 80 hour weeks!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi