The Point of the Story

Earlier today I blogged about a couple of the issues facing our group of Feature Teams at work. In the course of that blathering I mentioned Story Points, incidentally. As I did so, I was tempted to stop that blog entry and start another one just about Story Points, since they're so near and dear to my heart these days. Instead I showed restraint and finished what I'd started.

But now I feel the urge to talk about Story Points. If nothing about Agile or estimation interests you, you'll likely want to skip this one. I'll be back writing about movies, TV, comics and things that make me go "Huh?" soon enough, I promise.

My introduction to Story Points happened in the early days of us looking into Agile. I was reading what was probably my third or fourth Agile book, Agile Estimating and Planning, by Mike Cohn. In it, Cohn talks about the two main options for estimating in an Agile world: Ideal Days, and Story Points. The former was already known to me, as most estimating is done that way and then some sort of productivity factor is applied to convert the Ideal time to Real time. For example, if a person said they needed 2 weeks to do something, and it was clear they were picturing ten uninterrupted days of full productivity, but you knew that they'd probably spend about a third of a typical day attending meetings or dealing with distractions, then you'd take 10 Ideal Days and convert them to 15 Real Days, and expect the work done in 3 weeks, instead of 2. On the other hand, if the person providing the estimate said they'd already factored in meetings and the rest, and you trusted that they know what they're talking about, then you'd know that in fact they'd already provided you with a Real time estimate, rather than an Ideal time one (Ideal time might still show up in how much time they charged against the project, but that's a different consideration than planning). Simple stuff.

Story Points, on the other hand, were new to me. Cohn introduced them in a variety of ways, all of which were intended to get across two key facts: that Story Points are a relative, rather than absolute, unit of measure, and that they're more like weight than time. In his book, and again when I had the one-day tutorial with him in Las Vegas, he makes the case for thinking of them entirely in relation to each other, like when I say, "Bigger than a breadbox? Smaller than a Honda Civic?" Along the same lines, when someone asks you to estimate something in Story Points, don't think of how long it'll take; think about how big (or heavy) it seems. That's the first unexpected aspect of Story Points, since you go into the exercise believing estimating is all about elapsed time. And of course it is, but in a roundabout way when you use Story Points.

Why go roundabout, though? Well, Cohn suggests that Story Points are best used when you have a lot of work to estimate. If someone asks you, or your team, to estimate a single feature, or bug fix, there may not even be a need to use Story Points, since you can probably do a detailed task breakdown in that case and come up with an hour-based estimate, within a reasonable time. But when you're presented with half a dozen such requests, or a dozen, or several dozen, the task breakdown approach doesn't scale well at all. For one thing, it's too much work; for another, with that many feature requests, chances are some will take a long time - maybe forever - to get approved, in which case all of that detail work was wasted. That's where Story Points save the day. A good Agile team can knock off 15 - 20 estimates, in Story Points, in a couple hours or less. Now, clearly those estimates can't be as fine-grained as what you'd get out of a task breakdown, but they're not intended to be. Story Points are a gut level best guess at the size of the work, in terms that are relative to each other.

Which brings us back to the concept of them being more about size and less about time. This is the part that seems to be the hardest to get your head around. Cohn has a four word sentence for this, that we had pounded into our heads in Las Vegas:

"Estimate size; derive duration."

What he meant by this is that you're using Story Points to compare features (or bug fixes) to each other. You're saying "this one's an 8, and that one's a 5, and we all agree that one over there, that's a 20 if ever we saw one!" but you're not (yet) saying how long any of the three of them will take to complete! What you are saying is that the 8 Story Point feature will probably take almost twice as long as the 5 Story Point one, and that the 20 SP guy will take something like 2 to 3 times as long as the 8 SP fella. But is 5 Story Points a day, or a month, or somewhere in between? The answer is: you won't know, until you do some! "Estimate size; derive duration." The only way to derive the duration is to implement some features you've Story Pointed, and then see how many Story Points the team can deliver in an Iteration. That will give you at least some notion of the approximate duration. On my Feature Team, for example, the very, very early indication was that a single Story Point was something in the ballpark of one person, working for a week. Maybe in some cases that's actually going to turn out to be 2 or 3 days, and in others will be closer to 2 weeks. Since the Story Points are just estimates, we don't expect them to be precise. In fact, their usefullness decreases as you reduce the number of estimates in consideration. One particular feature may end up being a lot less, or a lot more, work than was estimated; but over a set of Story Pointed features, the highs and lows will average out to something very useful. And since you arrive at each Story Point estimate relative to another one, by gleaning some info about one estimate by actually implementing the work, you learn a little bit more about all of the remaining Story Pointed work. Which seems like a cool thing to me!

Once I got all of that straight in my head, I really started to like Story Points. They're a brand new tool for my toolbelt (after 20+ years of doing estimates), and one I love being able to pull out when the situation calls for it. I see a lot of other groups using them at work, too, and am amazed at how quickly they caught on. That was one of the pleasant surprises of our Going Agile. We've had mild pressure from certain parties to try to develop a company-wide Gold Standard for a Story Point, but fortunately the expert (Cohn) argues strongly against this, and so we've been able to push back on that request. I certainly understand where that desire is coming from, but it also shows that there's still a lot of confusion about Story Points. At times like that, I wish everyone could be on a Feature Team for at least a couple months, because that's probably the best way to see what does and doesn't work. And a few people could really benefit from that, I suspect!