The Humble Story Point

The Humble Story Point

I’ve had some interesting discussions lately on the management of work through user stories. A lot of teams, especially those just starting to use agile techniques, seem to have quite a bit of uncertainty around some common topics :

  • The theory behind story points and why they are preferred over estimations in hours
  • Why story points and velocity are self-correcting measures
  • The sizing process and appropriate sizes for stories

The problems with sizing in units of time

I’ve had the opportunity of working on several waterfall projects. I feel blessed to have been in these teams because I now recognize that:

  • Most estimations in hours are completely thumb-sucked. Given that software development is an incredibly complex beast, how can we possibly forecast time to be spent on a specific task in an accurate fashion?
  • Work break down structures are frequently used to aid in estimations, even though they exasperate inaccuracies of estimation at lower levels.
  • As teams typically contain members at different skill levels, how long a task takes depends on which members of the team actually do the work. An estimate based on time does not make sense in this context.
  • Traditional project management focuses on getting projects on time, sometimes sending teams on a death march and severely compromising on quality.
  • Waterfall based software teams are held to completely inaccurate estimations. The Gantt chart proves to be completely inflexible as the focus of the traditional project manager is on staying true to the original plan.

It should be obvious that I’m not a big believer in time-based estimations. Apart from the above, one should also watch out for the problem of local safety :

If asked how long a small task will take, a developer will naturally not want to deliver it late. After all, this is a small task, it should be on time or the developer wouldn’t be professional. Hence, the estimate will include a buffer to absorb the developer’s uncertainty about the task.

The estimate given by the developer will depend on how confident that developer is that he has understood the task and knows how to perform it. If there is uncertainty in the understanding of the task, then the estimated time to completion is likely to be significantly longer. No one wants to be late with such a small task.

The Agile Management for Software Engineering book also describes the need for a “relative” estimation method :

Accurate project planning techniques must avoid asking developers to estimate small tasks based on effort. The tasks to be performed must be broken out based on some form of (relative) complexity and risk. To work best, this requires a codification scheme for assessing the complexity and risk. An analysis method that enables small pieces of client-valued functionality to be codified for complexity or risk is required. This enables the inventory in the system of software production to be estimated without the psychological effect of local safety.

We have an alternate estimation method readily available in the form of story points. Jeff Sutherland explains why story points are better than hourly estimates:

The way we do story point estimation gives better estimates than hourly estimates as they are more accurate and have less variation. A CMMI Level 5 company determined that story point estimation cuts estimation time by 80% allowing teams to do more estimation and tracking than a typical waterfall team. A telecoms company noticed that estimated story points with planning poker was 48 times faster than waterfall estimation practices in the company and gave as good or better estimates.

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

Measures that work for the team

Given that story points are better than time-based measures, what is the unit of a story point? The most common sizing measures are T-Shirt sizing (S, M, L, XL), and the Fibonacci series (1, 2, 3, 5, 8, 13, 21, 34).

I prefer having less numbers to choose from since we can complete sizing faster by eliminating debate on the exact size of a story. My vote goes to the limited Fibonacci sequence (1, 2, 3, 5, 8), also in use by one of my favourite online tracking tools. I’m not impartial to the other estimation units though - even a simple scale of (1, 2, 3) could be of use to a team.

It’s all about averages

Points are about effort, not complexity. A team’s velocity is the amount of points completed in a sprint. Based on the velocity of the team in a previous sprint, we can forecast the amount of work the team should be able to do in a following sprint with reasonable certainty.

Velocity and story points are entirely based on the environment and members of the team. A new addition to the team, for example, might change the definition of a story point, and will have a direct effect on the team’s velocity. An awesome property of velocity and story points though, is that they are self-correcting measures. Since the team’s workload is derived from them, it will also adjust accordingly to any change in the team or environment. Wrong estimates also tend to average out - while we underestimate some stories, we also overestimate others.

Estimating in story points

With story points being an arbitrary measurement, how do we estimate in a consistent manner? There is no hard answer to this, except that you get a “feel” for the effort represented by a story point. The definition of a story point is unique per team, and it will only take a little while before a team synchronizes on the magnitude of a story point.

For teams new to story points, Chris Sims details an approach to sizing by sorting stories according to size that will make it easy to get started.

One can also try creating a personalised relative scale for points, with reference to previous/familiar work. For example, the following scale might be used to size stories :

  1. Adding a button to a page
  2. A form with a single text box, required validation.
  3. A form with multiple inputs, required validation, saved to the database.

And so forth. Craig Heckrath introduced me to this technique, and it seems to work well in teams completely new to agile.

More experienced teams tend to play planning poker since it

  • limits discussion and gets stories sized faster
  • keeps everyone in the team contributing to the discussion
  • is fun!

More on story sizing later.

Photo by sydney Rae on Unsplash

agile 

See also