What's the Deal with Story Points when Estimating?

About a year ago, a buddy of mine asked me to help him install a car stereo he just bought and I readily agreed provided the beer was provided and my wife would let me out to play for the weekend. We sat down to figure out everything that needed to be done, took into account our expertise (I'm handy with a multi-meter and graphing calculator and my buddy has spent some time working on his car before), so we felt like we were over-budgeting when we said we could get it done in a weekend. Should be plenty of time.

Three weekends (plus a few weekdays), a very angry wife and a disheveled garage later we finally put the faceplate back on, plugged the battery back in, powered up the fruits of our labor and it was good. The problem wasn't that we couldn't do it or that we didn't have the resources or even that we didn't have the time. The problem was actually very simple, we hadn't done it before so of course we couldn't estimate our time correctly.

Chances are that you have a story that is at least a little similar to this. I want you to stop and think about that the next time your sitting down with a developer to discuss the number of hours they'll need to fix a bug that they just learned about 10 minutes ago.

See where I'm going with this?

Force an estimate out of a developer with a definite value and you're going to get one of two things:

• A thoroughly underestimated work item


• A thoroughly padded estimate

Neither of which is useful in the slightest when it comes to planning a successful sprint. Things get even worse when you consider that a bug might take a senior developer 2 hours to fix whereas that new intern may spend the entire day plugging away at it. We need a better way to estimate if we're going to have a successful sprint.

Let's loop things back in with that developer who's estimating.

Let's ask our developer to rate a bug from 1 - 10, 1 being "Easy" and 10 being "uninstall realplayer for good this time". That's the kind of thing that's hard to pad an estimate for since a developer who rates a bug at an 8 will probably take the same amount of time for something else rated at 8 later on. More importantly this gives us an average that we can actually normalize over a team while developerA may take 10 hours on an 8 Story point work item (on average) and developerB may take twice that long (on average) by averaging things out we're able to come up with a reasonable workload for the team over the duration of a sprint without stressing about dev-hours.

So we've got the basic concept down, hours are inaccurate and create false expectations which lead to even more inaccurate estimates which in turn leads to ulcers for everyone involved. Story points offer us an abstraction layer but the way we've been talking about still has some problems.

What happens when we get a work item that rates higher than the last 10 we implemented? We need to remove the upper limit from the scale and it'd also be nice to have an increment so we're spending time arguing among the team if an item is a 7 or 8. So story point estimates should be open ended (within reason, if something is too big then break it down to create smaller work items to plan with). We should also increment story point estimates, which is most commonly done in fibonacci numbers. This means that I can estimate a work item as 1, 2, 3, 5, 8, 13, 21... story points. The bigger an item is, the less accurate the scale so we move in bigger increments.

We now have a scale to plan with, we planned 100 Story points worth of work last sprint and failed miserably. We finished enough work items to total 80 story points so we'll plan that for the next sprint.

Each team will have a different scale of story points, teamA may estimate a work item at 21 story points and teamB may estimate at 13. TeamB isn't faster, they just think of story points differently. On the flip side, Team A may finish 1000 story points worth of work in a sprint and team B finishes 300, once again, team A isn't faster so much as they simply tend towards larger estimates. Focus on having the team estimate and commit to their own work since an estimate means next to nothing outside of the team and coach the team to base what they commit to in a sprint off of past performance (if you don't have any info on past performance then your first sprint will suck, but that's okay ).

And that's it, remove hours from the discussion when estimating and planning a sprint, focus on complexity and past performance and the team when planning a sprint and you're good to go.

Do you have to use story points to plan a successful sprint? Heck no, plenty of Scrum teams estimate in hours and have great success, in fact, check out THIS article our CEO at Axosoft wrote on Scrum. Among other things he lays out a way to estimate without story points and it works great. The point here isn't to tell you the right way or wrong way to do thing (as if such a thing could exist for a development team), the goal is to put another tool in your hands to fix problems that might arise.