Story Points – do they really matter?

Posted by Jack on November 19, 2009 in Product Owner Analysis, Product Owner Planning, Product Owner Team |

There is so much talk about planning in Scrum.  The basic questions are around how you handle your sizing of user stories.  Also related is the discussion about how to handle situations where a story is sized but doesn’t get done in a Sprint.  Do you carry the points over, resize and so on. Here are my thoughts from a post I made to the Scrum Alliance Google Group.

How complex are we really making this?  It seems overcomplicated and takes away from some of the core reasons I find Scrum beneficial and useful.

As a Product Owner, I view the process as the following:

A)  Request for a project is received
B)  Initial “High-Level” User Stories are written
C)  Team uses Poker Planning, t-shirt sizing (or for one of my teams animal sizing) to measure the relative size of the stories.  We do this using a baseline story and ask, how complex, difficult, hard to know is this story compared to baseline story
D)  I use the cost of the team (payroll, hardware, software, etc.) and the through-put (average velocity per Sprint) of the team to determine cost per point.  This tells me estimated cost per sized story and therefore for the project
E)  From experience (and in a post I made here most of you agreed), I multiply a buffer of 2-4 times the teams estimate and provide a cost range estimate for the project.  The cost will be between $xxx,xxx (based on teams estimate) and $xxx,xxx (based on my multiplier).

If we move forward with the project then the user stories are broken down further and resized (1 high-level story might become 12 stories). If the cumulative cost of the 12 stories will impact your overall plan (timeline and cost), then be transparent immediately and share that information with your stakeholders.

Now to the question about how to handle story points when a story isn’t done by the end of the Sprint?

While it would be nice to hear and know what your best practice is regarding this question, how big of a deal is this really?  As long as you are having a retrospective and you address and fix the issue of stories carrying from one sprint to the next, it won’t have that much of an impact on the average velocity and therefore doesn’t greatly impact the figures I use for planning.  Just do what makes sense in your shop.  If you don’t like it, talk about in your retro and hopefully you have enough freedom and self-managing permission that you can make the changes to fit your team and operation.

Tags: , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Copyright © 2009-2010 Agile Product Owner Blog All rights reserved.
Desk Mess Mirrored v1.7 theme from BuyNowShop.com.