Understanding Agile Story Points Effectively

Understanding Agile Story Points or Scrum Story Points seem quiet challenging if you are only experienced with time based estimations. This post hopefully eases the situation and makes Story Points clearer.

Story Points are commonly used in Agile software development. When talking about Agile software development we are talking about Scrum in most cases, but there are other methods as well.

History

Historically Story Points arise from a military context, when during the Cold War the Delphi Method was developed to forecast the impact of technology on warfare. The goal was to get a forecast or estimation of probability and expected development time of a certain technology in a single indicator. The Delphi Method was then developed further into Wideband Delphi. Planning Poker, a widely used agile estimation technique, is a variation of Wideband Delphi.

What Story Points Are…

But back to Story Points and what they are. As mentioned before, Story Points are a single indicator that gives an idea of a variety of inputs, such as the level of complexity, knowledge base, effort, time, etc. Basically just a number used as an estimation measure. That number gives you an idea what the work items will be like and that number is sufficient as an estimation and for planing.

Using Story Points

A tricky part of using Story Points for people experienced with other estimation units, especially time, is to get rid of mapping Story Points to that unit. Another point is not to complicate Story Points with thinking too deep about all the inputs. Instead you want to put estimated work items in relation to each other. This gives you a better indication of what the risks are and what is easy to get done. There are many estimation techniques out there that work perfectly well with Story Points.

In case your team is struggling using story points, use other single indicators that people are already familiar with. It doesn’t have to be Story Points at all cost. We have very nice single indicators in daily use already, such as small, middle, big, bigger, too big. Using shirt sizes is a more creative way to put a single indicator for a work item. For planing purposes you’re allowed to map them to digits of course.

Once Story Points or a single indicator equivalent is used the right way, estimation and even implementation is more fun. It frees you from time estimations which will be wrong most of the time anyway (because it’s an estimation not a prediction), but others still hold you accountable for it. You have one single indicator per work item, that gives you an idea of what it takes to complete it. Sum up the single indicators of work items and you get a single indicator of what the team is capable of achieving per time unit. Planing with that is less time consuming and gives sufficient accuracy to work with.

There is a lot more to tell about that subject, but my goal was to keep the post short and bring story points closer to you.

Sources & Links:

• Delphi Method
• Wideband Delphi
• Planning Poker