Monthly Archives: April 2015

Adventures in Story Points

Story points are a corner stone of the agile development process, giving a key piece of information from those that implement the story to those that decide what gets built. It’s not the only piece of information that goes into planning at the product level, but it is the most important from a process point of view. Story points don’t just estimate how long a story will take, but bundle in estimates of technical risk and uncertainty. From a PM’s perspective two stories can sound the same, but end up with a large gap in the estimated story points. This could be because the engineers are deep within the code base that pertains to one story and not the other; and thus feel more confident about exactly what needs to be done. Or it could be because some things sounds easy to implement but aren’t. In my days as a consultant I’ve seen story points described in a few different ways:

  1. The number of days an engineer thinks it will take.
  2. An estimate of the size and complexity of a story; time estimate + risk factor
  3. A comparison of how big one story is to another; story1.size == story2.size

The pure agilest will tell you that story points are #3, but in the real world its hard to compare the size of a story with another without giving an inherent engineering hours estimate. Where teams get in trouble is when they start measuring their velocity from one sprint to the next as a ‘team performance metric’. If engineers get hounded when their velocity dips they are incentivized to either over-point or give points in terms of time, aka method #1 which is a flawed way of pointing a story. Points are for size which why we estimate hours for story tasks during sprint planning as well, because you have the best ability to judge how long a task will take right before you start it. If you point a story, and it sits for six months in the back log and then comes out and the assumptions around implementing it have changed, like say it was pointed assuming a certain library would be available and now the legal team has nixed using that library, then you’re going to be in trouble when it comes to measuring your velocity. Ideally you’d re-point anything that has sat around that long, but unless someone flagged that story as dependent on library xyz then the team might miss the fact that it no longer has accurate points.

A team’s velocity will change over time. So using story point velocity as a golden ruler of performance will make for a lot of unneeded stress. As a project moves from laying the architectural framework, to fleshing out all the details the team will gain or lose velocity depending on everyone’s abilities, throw in team member churn, ramping up new members, triage meetings to support legacy code, taking time to fix bugs and seeing a downward velocity in story points per engineer per sprint isn’t unheard of.

So how should you use story points? There is no perfect solution. And that’s what agile is all about. You have to find the right implementation for your team. How’s that for copping out of a decent answer? On a more specific note I tend to favor deciding how many points an engineer should take in a sprint first, and then using that as a measuring stick for how big a story is. As an added bonus to help keep story points consistent over time I find it helpful to pick out stereotypical stories during sprint closing as a reference for future grooming.

Story points are an integral part of the agile development process, and it’s one that is often contentious.  I’ve found it helps to have a written definition of the teams interpretation of story points (a long with all other process terms) to ensure everyone is on the same page.  So, don’t fall into the trap of militant Points per Sprint velocity measurements or bickering about what a story point means each print. In the end, story points are what you make of them.