Dave Churchville recently expounded on ideal days versus story points:
Personally, I tend to prefer the ideal time units, since it’s easier to explain to customers, but I have heard reports that point systems have had good results as well after the initial confusion.
My problem with story points is the teams have never gotten over that initial confusion. I’ve used story points mostly since attending a convincing talk on ideal days versus story points by Mike Cohn at SD West 2005. We’ve done many ‘planning poker’ sessions with cards and story points. I think some developers enjoyed the game aspect a bit, but our estimates haven’t been that great.
Story points should work well if everyone on the team really gets the concept. The problem is especially early on most the backlog items you’re estimating are really ballpark estimates since there is no historical information and generally only a high level description of items. So you end up with some widely estimated story based on unknowns, not much relative comparison. We write use cases so it goes something like this:
Backlog Item #1: Maintain Batch Report Use Case.
Team: Umm, how about 5 story points.
Backlog Item #2: Convert all the legacy and historical data from the old schema to the new schema.
Team: Hmm, that sounds hard how about 20 story points.
Backlog Item #3: E-sign Documents Use Case.
Team: We’ve never done that before. After some discussion since everyone feels it’s still risky maybe 100 story points.
Facilitator: OK, do we really think E-signatures are about as much work as doing 20 reports?
When we deal with ideal days these discussions tend towards better estimates, because everyone is familiar with using time units. I still think story points are a great idea in theory, but I’ve fallen back to using ideal days because it hasn’t played out as well in practice.