Great post by Neil Killick about the problems with estimation

“Fixed” scope project delivery expectations are often (always?) based on an up-front estimate of scope (guess) and how long that scope will take to be delivered (another guess), leading to the obvious dysfunctions like death-marches, low quality, etc.

a guess   X  a guess = 1 mess

Asking teams to estimate how long their work will take (or how many points they will deliver in a Sprint or a Release, same thing) has connotations that their output is being measured by an external party (manager), creating an environment of fear and massaging figures to reflect what is desired rather than what is predicted

This needs a cultural change… which is not easy… 

To increase velocity the team simply needs to over-estimate stories to give the illusion of delivering more. They may not consciously do this but it may happen sub-consciously. The project manager pats them on the back, but all that has happened is the same amount of “done” working software has been delivered.

Result = developing features takes longer and longer, but at least the estimates are accurate…

We shouldn’t be defining all our scope up front, meaning we shouldn’t estimate all our scope up front, meaning we shouldn’t be defining our delivery date based on our scope

This needs trust in the team, which is related to point 1 (culture)

…the team does not need to be in an estimation session to discuss and break down a story.

+1 This highlights the importance of the Backlog Grooming meeting.

If it doesn’t need breaking down then it is likely already well understood.

How can the PO make trade-off decisions? 

The PO probably needs to know the ROI of a story when introducing it to the team to be delivered. In order to calculate the ROI she needs to know how much it will cost to be delivered (how long).

Here a team would estimate the item using story points and then the PO, armed with the team’s velocity, can estimate the item’s ROI. But without story points how can this be done?

Split all stories to be of the same size.

Great post by Neil Killick
http://neilkillick.com/2012/04/12/do-not-estimate-software-projects-at-all/