FB

4/20/2012

Making the Case for Story Points


Or: Why Story Points Outperform Man-Days easily

I introduced Scrum to a number of teams now. There was always big discussion whether estimation in Story Points is of any use. I think estimating in Story Points is one of the really great inventions of the Scrum framework and I want to draw out the reasons for this believe in this post.

Estimating in Story Points has great advantages in multiple aspects:

Team Advantages

  • Story Points are a team metric. They are always estimated by the whole team. In my experience those estimates clearly outperform man-day estimates, since they depend not so much on who actually carries out the estimated task. Thus Story Point estimates are more reliable.
  • Since everybody in the team participated in the estimation most people feel more accountable for the work behind the Story. This is often not the case with man-day estimates which are in many cases given by experts and carried out by someone else.
  • Since the whole team estimates, much more information is shared among team members. This supports reducing islands of knowledge.
  • In emerging discussions during estimation open questions and risks are discovered very early.

Abstract Number Advantages

  • There is no immediate connection between Story Points and real working hours. This makes estimation often much easier and removes useless points from the discussion agenda in estimation meetings.
  • Estimating in Story Points makes you almost immediately think a little more abstract during the estimation. You often do not loose yourself in the details of the implementation which makes estimation faster but still accurate enough.
  • Story Points are usually estimated in fixed and fastly growing steps (e.g. the Fibonacci Numbers). Therefore the amount of uncertainty and risk is simply expressed in the resulting number. The bigger the number - the higher risk and uncertainty. This is clearly expressed by not having numbers like 427 available (which would suggest high accuracy for outside observers).
  • You can estimate earlier in Story Points than in man-days. The reason is that you can much earlier say how big a task is relative to other tasks, than to determine exactly how many days you would need to implement it. Relative estimation seems to be easier to accomplish for human beings than absolute estimations.
  • Estimations in Story Points are often more honest than estimates in man-days. The reason is, that you do not have the feeling to "promise" to be done in X days.
  • Since the Story Point number is abstract you do not have the temptation to build in buffers. Thus you have much better control about the real state of work.

Efficiency Advantages

  • Estimation in Story Points is often much faster than classical estimation in man-days. Many of the reasons for this point are still mentioned above. Additionally, there are methods to get those estimates really fast (e.g. Planning Poker or Magic Estimation).
  • By estimating in Story Points you avoid unnecessary discussion and justification for the time needed ("Why can't you do this in three days? Five really seems a little to much...").
  • You additionally avoid useless discussions about teams performance ("you are three guys working five days a week - why did you only finish work estimated for six man-days last week?"). To be clear: discussions about teams performance (positiv or negative) are legal and often good hints for impediments, but not in the indicated tone. Thus Story Points can switch your attention from justifying to solving problems.

Self-Improving Mechanism

  • In my experience you get an excellent predictability for your projects progress with Story Points in early project stages. This is because Story Points contain a self correcting mechanism. Slow or fast progress will show up early in the project.
  • If you made some errors during your estimations the errors are very likely to be averaged out. Thus you do not have to care so much about the correctness of your estimates, which saves you good amounts of time.
  • The estimates in Story Points are self adapting. If a team changes, the mechanism adjusts itself immediatly. If the teams performance increases or decreases you do not have to re-estimate. All estimations stay valid and you can still easily predict progress.

I do not love to say this, but there are two disadvantages at hand with Story Points from my point of view:

Shortcommings

  • Firstly, they are hard to explain. Almost everybody is familiar with some estimation in man-days. The concept of relative and abstract estimates are difficult in the first place. But this vanishes after only a few weeks.
  • The second point is that in our times and organisations you often have to do some recalculation from Story Points to man-days for financial reasons. This is easy, but is work that generates only limited value.

If you have any other arguments on estimations in Story Points - feel free to comment on this post.

In essence, the central goal of estimations is to get the necessary metrics and information to make progress transparent. This is obviously possible with both, man-days and Story Points. But considering the huge amount of advantages of Story Points this - at least to me - seems to be the better and more efficient way to achieve this.

But after all - it's an estimation technique and the only thing you can be certain about is that it's to some degree uncertain.

5 comments:

  1. it's quiet interesting, precisely because you admit performance as a legal discussion of/about working teams. whatabout the (even possible) correlation of story points to function points?

    ReplyDelete
    Replies
    1. Function Points could serve for a complete blog entry on their own (and even much more)...

      Despite this, here some thoughts on this topic:

      Why should one try observe correlations between Story Points and Function Points? I do not see any benefit in this. And I think both measures have different objectives:

      Function points try to compare and trace performance in software development, by counting specific implementation details (number of input fields, complexity of database, etc.). They pretend to be an "objective" measure, which can be (and is widely) discussed. Function Points want to make things (e.g. teams, development environments, etc.) comparable.

      Story Points are not meant to be an objective measure of performance. Every team sets its own Story Point scale and every team is likely to change that scale in the long run. Thus Story Points are not suitable to compare the performance of different teams or even trace the performance of one team over a long time period. The purpose of Story Points to help the team with planning issues (sprint planning), tracing progress of the teams work and (if declining suddenly) giving strong hints, that there might be big impediments to remove.

      Delete
  2. Hard to explain? Maybe not. SPs are about the amount of work to do, not about the effort to be made.

    Usually, I explain it referring to Popeye and Olivia ;-) Carrying two crates of water vs. five crates from the garage up into the hallway represents two amounts of work. The 2 or 5 minutes, respectively, it takes Popeye to do this vs. the 3 or 7.5 minutes minutes it takes Olivia represent the respective efforts.

    Story Points are about "crates", not about "minutes". That's pretty much it.

    If Popeye becomes a fat couch potato and Olivia starts working out in a gym, the respective efforts might change, but the number of crates in the garage still remains the same.

    ReplyDelete
    Replies
    1. Hi Rolf,

      I really like your idea to explain this with Popeye an Olivia :-)
      Thanks for sharing!

      Delete
  3. This comment has been removed by a blog administrator.

    ReplyDelete