I get this asked quite often as well. 

Q: Are story points an excuse for teams not being  able to estimate correctly in days/hours? 

A: The effort and time required to arrive at an accurate number in days/hours for a story weighs against the benefits of estimating as such. Moreover estimating in days/hours puts undue pressure on the team to deliver within those number of days, leading to the team unable to reach a sustainable pace, and possibly burning out .

Additionally:

if we have an estimate in days:

• I see the “illusion of control” or the “pretend to be in control” phenomen
  and
• Developers tend to follow the “Parkinsons’s law”
  “Work expands so as to fill the time available for its completion.”

Great paper from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf

This is something I get asked a lot in my current project.

Q: How do we know if the team is getting better at estimation when it is estimating in points?

It is a popular belief that if the team were to estimate in ideal days, then it would be much easier to track if the estimation is accurate, by checking the actual days elapsed on a story and the progress against it. This is however counterproductive as the team spends hours to estimate few stories to arrive at the magic number of days before being pressurized to deliver on that magic number.

When a team is relatively sizing stories in points, a trend slowly starts emerging where similarly sized stories start showing similar time to implement them. If there is a bad estimate, then that bubbles up automatically as an exception.

Great interview with Anand Vishwanath in this PDF from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf

Nice article about

1. Time abstraction
2. Focus on little bits (Time wise and split up stories and tasks)

From experience, I know it takes a certain amount of time to add one brick to a wall. Adding additional bricks will take about the same amount of time. Therefore, I can give you a somewhat accurate prediction of how long it will take to build an entire wall.

Writing software, like Finding a Cure for Cancer, is more a research activity

3 concepts from Scrum which can help solve this problem of estimation:

1. Estimate using Story Points

Story Points are not part of Scrum, but anyway a good abstraction from time.
The biggest advantage is that they force you to estimate relatively!
[Advertisement] Come to my class to see this in action ;-)

2. Work in Sprints
3. Break Stories into Tasks

…management cannot accurately estimate the business value of a project until a project begins

This requires trust and a couple of Sprints to get a feeling on how the Dev Team is going

Demanding that a developer provide a time estimate forces the developer to lie and no one likes to lie.

In addition, every developer follows the Parkinson’s Law

   ”Work expands so as to fill the time available for its completion.”

Full article
http://www.scrumexpert.com/knowledge/why-you-should-not-estimate-in-hours-or-days/ 

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

Read More

Great ideas to get some variety in your planning meetings

Remember #1 its not about the outcome (number) but about the common understanding

And #2 don’t forget to split your stories

http://scrumcoaching.wordpress.com/2010/08/14/estimation-techniques/

Great post by Esther Derby, where she explains how people use estimates and what value you get out of “estimating”.

I have come to value “Estimating” over “Estimates”

Esther Derby
http://www.estherderby.com/2012/03/estimating-is-often-helpful-estimates-are-often-not.html

I am not sure about the name…. but the technique works!

You could call it “Affinity estimating” but that is not as sexy ;-) 

Great article.
Best bit: 

“Stop when further planning is not likely to lead to improved decisions worth the extra effort.”

How bad are cost estimates in the US public sector? (Transportation, Energy, Defencse, Tech)  
—> Very bad.

Ask yourself: How bad are my esimates? (software industry)

#2

Potential source of these problems:

• “old-fashioned bungling by administrators”
• lack of government to take responsibility
• “lying, or intentional deception, by public officials was the source of the problem”
• No interest in cost efficiencies
  —> costs are benefits to politicians

#3

Never heard of the “salami strategy” before… LOL