http://www.infoq.com/articles/agile-estimation-techniques

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.