The Point of Story Points

Planning PokerWhen answering the question ‘why story points?’, it’s easy to focus on the benefits of story points and relative estimation over other forms of estimation.  However it’s important to answer this question in an even more fundamental way.  Once we create story point estimates, what can we actually use them for?  Are they worth creating at all?

Cost vs Benefit

When prioritising the backlog it can be useful to not only consider the value of the piece of work, but also the cost in terms of development effort.  Quick wins, which are items with high value but low effort, may be prioritised against low value items requiring a lot of effort.  It’s also possible that if the gap between the value delivered and the cost to complete it is large enough, that the business may choose not to spend the time at all.  Remember that the Product Owner is tasked with maximising return on investment.  Story points allow the Product Owner to make decisions, ideally without the team having to spend a lot of time on items that may never be implemented.

Delivery Times

Story points, when combined with a team’s historical velocity, also give us an indication of when a feature will be delivered.  This delivery date is at least based on past performance rather than hopes and dreams, yet it is important to note that it is still only an indication.  Estimates are estimates and, when working on complex products, it’s always possible for something to go wrong (or right!).  Despite that weakness, story points do at least give us an idea of how we’re tracking as we adjust the estimated delivery date with velocity.  As we progress through the work, our estimates get more accurate according to the cone of uncertainty.

Productivity

By measuring velocity, we get an indication of team productivity.  If the team is able to take on more story points, assuming that the stories are relatively estimated, then this suggests that productivity has increased.  This metric comes with a major warning however.  As soon as teams start focusing on increasing their velocity, or managers start evaluating teams’ on their velocity, the metric will become useless.

You get what you measure because people are smart and every metric can be gamed.  When using velocity as a productivity metric, it only gives you a starting point for trying to understand which types of work slow the team down and which help the team deliver more.  As soon as you link a drop in velocity to the idea that the team is slacking off and not working hard enough, you will get one of two things.  The team will inflate their story point value so that it looks like they’re delivering more.  Or worse, given your lack of trust, the team will decide to live up to expectations and stop trying.

Conversation Trigger

Possibly my favourite purpose for creating story points is as a tool for triggering conversations.  Asking why an item is estimated twice as large as another can help to uncover underlying assumptions and improve understanding between the team and the Product Owner or customer.  Of course there are many other ways to uncover such assumptions and story points shouldn’t be the only tool in your belt for doing so.

Hopefully that gives you some insight into how story points should be used as well as warning you away from the basic pitfalls.  I would recommend that if you don’t need estimates for any of the above reasons, then you probably shouldn’t be spending time creating them.


Related Books:

Software Estimation

Steve McConnell
2006
User Stories Applied

Mike Cohn
2004


Categories: Artifacts

Tags: , , , , , , , , , ,

5 replies

  1. Hi 🙂

    I think we would have a long interesting chat over this topic… I have exactly the opposite opinion 🙂 Story Points destroy team spirit and productivity 🙂 It is not accurate at all 🙂

    Take a look into these blog:
    http://softwaredevelopmenttoday.blogspot.de/2012/01/story-points-considered-harmful-or-why.html

    Cheers,
    Luis

    • Story points are indeed interesting. I didn’t say that story points don’t have any problems, I merely believe that if you are going to use them, you should know what you’re using them for. Avoiding the problems of story points is a blog post in and of itself! Perhaps several posts even.

      But you also need to be careful about what are the weaknesses of story points, and what are the weakness in the ways people are using them. I have seen organisations who have had story points work effectively for them, and others that haven’t. Different things work for different people.

  2. Ahhh I saw that you were trained by Mountain Goat 🙂 That is the reason 😀 😀

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: