Yes. and sometimes it's all about winning a tender or sales bid and getting a feel for what the client's contrainst are (time, cost or scope.) 

Great point, Craig! 

As of yet, I have not been involved with an Agile project team from the start, only been dropped in the middle of the project :-)

From what I've read, in the purest form Agile is supposed to iterate 'forever' until the business feels like the software accomplishes 'enough'.  The only thing you can measure at the beginning is how long an iteration will last.  Management could come in and say 'fine, you have 3 iterations to get this done', but that conflicts with Agile ethos.

I've had a PM whose worked in a Scrum setting before.  What his team did was a modified rolling wave - create estimates for each task that was to be performed in the iteration (based on their estimate of how much they could accoplish).  Then at each daily scrum they would go through the tasks currently being worked on and see how many hours were left on that task (not how many hours were worked on it).  As hours got ticked off, they would use a 'burn down chart' to estimate how close they were to their estimated results, based on time elapsed.  It seems like an interesting way of doing things, but still leaves the question open to 'what will/must you build' at the beginning of the project.

On larger size projects it should not be the responsibility of the project manager to come up with guesstimates or estimates. The PM’s role is to manager the project not to dictate.

On one of my recent large projects, the PM requests estimates from the execution team (analysis, development, QA) at all points in the project: upfront sizing, estimates based on initial requirements, and final commitment based on agreed upon requirements. This type of process takes discipline from both sides but, if that is in place, works very well.

Specifically for business/systems analysis, the analysis manager or a team lead provides the initial estimate based on vision and high-level requirements. Once the requirements are validated the business systems analysis team lead provides committed numbers based on a solution document which outlines the concept of the solution. Something similar happens for the development and QA teams.

Of course, any key stakeholder on the project (project sponsor, PMs, solution owner, etc.) can question an estimate if it does not make sense.

In general, this process works very well because:

• morale is high because the agreed upon timelines are based on reality and not on stakeholder's or upon management's wishes,
• the actual delivery dates tend to stay very close to the committed/promised dates,
• it avoids setting unreasonable expectations which can't be met,
• it gives the project team a sense of ownership.

The reality is that most Project Managers, while they may be excellent at managing the project, they do not have detailed knowledge of business analysis, systems analysis, software architecture and design, coding, QA to be able to come up with a good estimate.

- Adrian