Mike Cohn in Agile Estimating and Planning describes estimation using story points vs ideal days in Chapters 4-5, then compares them in Chapter 8. Regarding research:
There is credible evidence that we are better at estimating “this is
like that” than we are at estimating the absolute size of things
(Lederer 1998; Vicinanza 1991).
The sources of these citations are given as
In general, ideal days may be easier to comprehend for some people / teams, however the risk is that it is too easily interpreted (even unconsciously) as concrete days (elapsed time), which then may even be viewed as a commitment (by e.g. management). This is mainly why story points are used by many, to avoid any chance of misinterpretation. With story points it is always clear that we are estimating relative size, not duration.
It may also be important to note that story points can not be directly translated into effective task hours / days; over a longer time period, a team of course is able to calculate how much time a story point may take to complete on average; however that does not mean that you can use that value to calculate the time required to complete a specific item. In real life, a concrete item of 2 story points may turn out to require the same amount of time to complete as another item of 1 story point - or it may require 3 times as much time. However, in a larger sample these individual fluctuations tend to cancel each other out nicely, hence story points can be used to estimate team velocity in the long term.
Mike himself clearly favours story points:
My preference is for story points. I find that the benefits they offer
as pure measure of size are compelling. That story points help promote
cross-functional team behavior is a huge advantage. Shifting a team’s
thinking from “my part will take three ideal days and your part will
take two ideal days so the total is five ideal days” is very different
from “overall this story seems about the same size as that one so
let’s call it five story points also.” That a story point to me can be
the same as a story point to you, while the same may not be true of an
ideal day, is another big benefit. Two developers of different skill
or experience can agree on the size of something while disagreeing
about how long it will take to do.
The shortcomings of story points are indeed short. Yes, it’s easier to
get started with ideal days. However, the discomfort of working with
nebulous story points is shortlived. Ideal days are definitely easier
to explain to those outside the team but we probably shouldn’t choose
based on how hard it will be to explain to outsiders. That ideal days
are so easily understandable causes problems as well. In some
organizations there will be pressure to make an actual day closer to
an ideal day. Pressure for more focus and concentration on our work is
fine. But organizational pressure for each actual day to be close to
an ideal day will also have the effect of causing us to estimate in
actual time while calling it an ideal day. That is, an ideal day will
become redefined as “a day where I make six hours of progress and do
other things for two hours.”
Just bumped into another article from Jeff Sutherland's blog with research details and links:
Story Points: Why are they better than hours?