The above article is a good overview of the Agile Estimation process.
I would disagree on one important point, however. And it’s a point most agilists would disagree with me on: I believe the ‘planning poker’ approach to estimating works best in the early inception phases of a project, and again for release planning.
But, at the end of a detailed discovery phase and before you start your first productive sprint, you should also know enough to estimate or at least explain:
* All key functions or features in ‘worse/best case’ scenarios
* The staffing and oversight needed (PMs, Product Owners, QA manager, etc.)
* The key risks: As in the likelihood that services won’t be ready, or the likelihood that servers won’t be ready, etc. and the impacts those possibilities would have on team productivity.
* Unproductive time like meetings, vacations, holidays, sick days, etc. that you know will affect output and you know will occur with teams of humans.
* Vendor costs and licensing fees.
If you aren’t able to articulate at least the high/low estimates of the above (whether or not these contingencies are contained in your point calculation) before you start your first sprint, I would be suspect of your experience in the craft of delivery.