When I first started using Extreme Programming I estimated user stories in ideal time . Later, when velocity replaced load factor , I switched to story points .

A story point is a measure of magnitude. It's also a measure of the size of a user story relative to other user stories. Story points enable effort to be estimated without trying to estimate how long it will take. To derive an estimate for the duration of a project you divide the story points for all the user stories by the velocity of the development team (given by the number of story points completed in the last iteration). User stories can be estimated quickly using triangulation, e.g. I'm giving this story 2 points because it feels like it's twice as big as that 1-point story and about half as big as that 4-point story.

I like the concept of story points , but I've seen development teams get confused by them and I've never met a customer who liked them. Why? Quite a few developers said something like: I get the idea but estimating with them doesn't feel natural . It's true that their abstract nature takes a little getting used to.

For developers, the real confusion starts when a user story's tasks are estimated in ideal time . After a while, developers think they see a correlation between story points and time. They think, for example, that 1 story point = 4 ideal hours. An equivalence such as this isn't valid because a story point value actually corresponds to a distribution of time. A 1-point user story may take 4 ideal hours to complete, but it's also possible that another 1-point user story will take less, or indeed more than 4 ideal hours. To counter this variation in time and preserve equivalence, developers start to estimate in ideal time first and then convert to story points . When this happens the purpose of using story points is lost. Paraphrasing James Shore , the net effect is increased confusion about how to estimate, and a corresponding decline in the team's confidence and commitment to their iteration plans .

Story points are equally unnatural for the customer, who's more used to getting estimates in time. I've often seen developers remind the customer that estimates are in story points and not time, to which the customer responds, Well what is it in time? This frustrates everyone and collaboration suffers because of it. The customer doesn't have an intimate relationship with the estimates like the developers do, so the estimates need to be easily understood. If the customer isn't comfortable with story points , he may not trust the estimates and that isn't good. The customer needs to trust the estimates because they reflect the cost of user stories, and he measures this against their value to the business in order to prioritise.

I was interested to read that Chris Wheeler had experienced similar difficulties using story points , and James Shore reverted to using pair-hours because he realised that making estimating units more abstract made estimating and planning more confusing and difficult . Kent Beck also reverted to using time-based estimates in the second edition of Extreme Programming Edition Explained . Is this a trend? I'm not sure, but I'm switching back to ideal time too. I want to see whether the difficulties I encountered using story points go away. And I want to see what new difficulties emerge with ideal time .

Reference: Mike Cohn's Agile Estimating and Planning