In Kent Beck's new edition of Extreme Programming Explained, he advocates using pair-hours instead of the more-common "story points" to estimate. I like this idea, because I've had some issues with story points.

Using pair-hours actually brings me full circle. On my very first XP project, we used "ideal hours" to estimate. Back then, the XP gospel was to estimate in ideal hours and multiply by a measured "load factor" to come up with a real-time estimate. We presented the real-time estimate to our customers and didn't have any problems.

By the time my next project rolled around, XP had abandoned "load factor" in favor of "velocity," which is just measuring how many ideal hours you can do in an iteration. We also measured the accuracy of our estimates, and found that our estimates were consistent but never accurate. The estimates were usually low. As a result, our velocity was pretty low, too, which resulted in questions like, "How come we're only getting 30 hours of work done when we have six programmers working three weeks?" We started calling the estimating units "story points" to avoid the question.

I introduced several teams to XP using this technique. Although we called them "story points" to the customer, we thought in terms of "ideal hours" (or days). This was dishonest, and we would slip and call them hours or days anyway. That didn't do much for customer understanding or trust. We'd get requests to increase our velocity, which doesn't make sense for an XP team, because velocity is a function of estimate accuracy and actual hours worked. Assuming the team's working full time, the only way to increase velocity is to inflate your estimates.

Since estimated ideal hours weren't the same as actual ideal hours (remember, the estimates were consistent but not accurate), and since it caused a lot of customer confusion, I switched to teaching teams to just use story points. I didn't tie it to ideal hours or anything--I just said that a 2-point story should be twice as big as a 1-point story, and don't think about time. (Joshua Kerievsky introduced me to the term NUT--nebulous unit of time--as a replacement for "story point," which I thought was dead clever, so I've used that, too.)

When I did that, though, I noticed a big jump in programmer confusion about how to estimate, and a corresponding decline in teams' confidence and commitment to their iteration plans. (This makes more sense if you remember that I work with a lot of teams that are new to XP.) I'm not saying the switch was the sole cause of this, but I think it contributed. Customers were just as in the dark as ever, too.

A recent conversation on the XP mailing list helped me realize what was going on. By making estimating units more and more abstract, I was making estimating and planning more and more confusing and difficult. It's no wonder teams were having trouble making and meeting iteration plans.

I'm going to go back to using ideal hours to estimate. Rather than disguise them with points, I'll be up front with customers about what's going on. If the velocity seems low, we'll either work to make estimates more accurate or we'll address the overhead that's sucking up the team's time. Either way, I expect the transparency of using ideal hours to be a nice improvement for estimation and planning.

In support of this theory, Chris Wheeler has a nice post about what happened when his team switched from NUTs to pair hours. Gunjan Doshi, Joshua Kerievsky, and I introduced XP to his team using the "abstract NUTs" approach. Chris reports that switching to pair hours made planning and delivery much easier.