Beyond Story Points and Planning Poker

If you’re unfamiliar with agile software development, the terms “Story Points” and “planning poker” may be completely mysterious to you. If you’re new to agile, these terms may have specific meaning to you that aren’t universally true. These concepts have a history, and are best understood in the context of that history.

Story Points

In the beginning, there was the Chrysler Comprehensive Compensation or C3 project, the birthplace of Extreme Programming. The short version of the story is that some very smart people tried some things until they got something that worked, and that included breaking up the work to be done into User Stories (c.f., ​User Stories​) that could be independently developed and tested. For planning purposes, these were estimated in “ideal days,” and later, unitless Story Points.^[1] The advantage of Story Points over estimating in absolute time is that it allowed you to calibrate your estimates with what actually happens. We’ll take another look at this calibration in ​Calibrating to Unknown Context​.

Planning Poker

James Grenning invented Planning Poker^[2][3], not to emulate Wide-Band Delphi estimation, but to get a stalled meeting moving again. While he continued to use and teach it, it was when Mike Cohn publicized the technique in Agile Estimating and Planning [Coh05] that the practice was widely adopted. Soon many people came to believe that Planning Poker was THE agile estimation technique, though James has gone on to use other methods.

Counting Stories

Back in 2008 or 2009, Bob Payne and I were noticing that teams we were coaching spent an awfully long time estimating their stories in Story Points. Even though they spent two or more hours every two weeks doing this, the estimates didn’t seem to jibe with reality. Figuring that the primary reason for estimating every two weeks was choosing how much would fit into the two weeks, we did some analysis of the data and determined that a count of the stories had as much predictive power (or a little more) than did these laborious estimates. We presented a session^[4] at the Agile 2012 Conference showing our conclusions. We were not, of course, the only ones to discover that counting stories, especially for the short run, was as good as estimating stories—and a lot easier.

Of course, nipping off a bite-sized chunk of work is only one aspect of looking ahead. Another common aspect is figuring out when some major functionality is going to be done. Chet Hendrickson tells me that they started with stories to fill 11 three-week iterations, or about 7-1/2 months. That’s a lot of stories to pin down at the start of the project, yet the C3 project had an onsite customer who knew that much about what needed to be done.^[5] I’ve witnessed a lot of customers who don’t, whether or not they thought they did. That’s made me very wary of starting with ​A Large Number of Small Parts​, as that also seems like a waste of effort for the value returned.