Three reasons why story points are better than ideal man days for estimations

I often hear from Scrum teams they don’t understand why estimating in story points are better than estimating in ideal man days. Here comes three reasons:

Reason 1. Estimation is a way of telling the size of a story, not how long it takes to implement it. If you give the size in a unit that sounds like a time people will likely mix things up. If you have persons in your organization who are control freaks it’s hard to explain why a story with size 5 ideal man days takes two weeks to develop. If one of the control freaks is your manager you will probably be asked to cut down on Scrum stuff like daily Scrum or retrospective or what ever you are doing the 50% of time you are not developing.

Reason 2. Scrum has a potential to make you four times more productive. Let’s say you are a development team of five people and have estimated a whole project in ideal man days and you start with a focus factor of 50%. That means you can include stories representing about 35 ideal man days in a three week sprint. Let’s say you actually become four times more productive which means you can handle stories with summarized size of 140 ideal man days in a timeframe of 5 persons * 14 days = 70 calendar man days which means you have a focus factor of 200%. Does that sound weird to anyone? Ideal man days is a size that varies over time depending on team performance. If you don’t understand the calculation the last paragraph might help you.

Reason 3. It’s proven that relative estimation is more correct than absolute and since ideal man days is a time measure it’s easy to make absolute estimations even though it could be used relatively as well. Story points has no meaning without something to relate to which means those estimates can only work for relative estimations.

My recommendation is to estimate in story points and use velocity to calculate the time just like you do for driving. The distance divided by your velocity gives the time it takes.

This is how you can get started. Take a well known task/story as your standardised benchmark. If this a rather small story, set it to two story points so you have room for smaller stories. Estimate the rest of the stories relative to this.

Before our first planning meeting we need to know our velocity so we know how much we can commit to. But we don’t have that since we don’t have a history.

To get an initial velocity for our first sprint, we estimate the selected standard story in ideal man days. Let’s say the story is 2 story points and 4 ideal man days, we then know the team can handle 1/2 story point per ideal man day. Use the focus factor to convert ideal man day to calendar days. The focus factor is typically between 50% and 70% depending on the amount of support and interruptions. If the focus factor is 50% we can handle 1/4 story point in a calendar day (1/2 * 50%). If the team consist of five people and the sprint is 14 days we have 70 calendar man days in the sprint. 70 * 1/4 gives that we should be able to bring 17 story points into the sprint. Finally we have our initial velocity.

Good luck!
/Tomas

5 Comments

  • 1
    December 5, 2008 - 3:39 am | Permalink

    Good topic! I agree completely, although I’ve been advocating the use of "Gnome Days" (which really is just a funny name for Ideal Days) on my blog (http://scrumftw.blogspot.com) and on other places. Recently I’ve realized the difficulties involved with this, which you pinpoint well here in your post.

    The reason for introducing Gnome Days in the first place was the pedagogical problem of discussing "size" without discussing time. In my experience it’s harder than it seems. Now that we’ve been experimenting back and forth with various approaches, and everyone has learned why we estimate in SP and learned the usefulness for the team of measuring velocity (which hasnt been so obvious either), we’re now introducing a completely relative and unitless estimation technique just as you suggest. We will identify and bring one or two reference stories that we know have a certain story point value and relate all new stories to those.

    Just to be sure we dont mix up the StoryPoint value with time in any way, we’ll add a zero to the values of a typical planning poker deck; e.g. we’ll probably use 5, 10, 20, 30, 50, 80, 130, 200 and so on as our values. Would you advise against that, instead of doing it by the book and use the more common values?

    This change in estimation technique will however render all previous velocity measurements and all previous estimations more or less useless I think… But I rather have something new and better and start measurments from scratch, than work in a less than optimal way but have historic measurement…..

    Cheers
    Richard

  • 2
    February 17, 2009 - 2:50 am | Permalink

    At a speech about Pomodoro Technique Staffan Nöteberg mentioned that most people feel uncomfortable about giving estimates in actual time. Aha, I thought. Uncomfortable people are less productive so estimation in days are less productive.

  • 3
    December 15, 2008 - 10:45 am | Permalink

    Good, to the point and really worth one’s while.

    Sure needed that one!

  • 4
    Prasantha
    August 30, 2012 - 10:54 am | Permalink

    Hi Thomas,

    This is good blog. BTW, have you come across with any situation when the points estimation doesnt make sense?
    Also, from estimation point of view, when should a re-estimation happen? As we learn more, team might say estimates of some stories are no more correct as we know more about them now. Should we re-estimate the whole backlog?
    Also, after a iteration, team might say one of the stories we played are bigger that it was to be. Should we put the correct estimate on that (so that the velocity is more accurate)?
    Thanks
    Prasantha

    • 5
      September 8, 2012 - 7:48 am | Permalink

      Hi Prasantha
      Nice to hear from you
      My suggestion is that you first decide why you do estimations. If it’s used for forecasting sprints and releases I suggest you update story estimates as soon as the team does not believe in them anymore. Don’t spend too much time on it though because the future is still unknown and hard to predict. I would not update an old story estimation. The advantage with relative estimation is that it doesn’t matter for predictability if our estimations are always too positive. The relative difference is still the same. If the estimation error is big and a one time occasion, I may see a reason to correct estimate. At the end, don’t put to much time on getting correct estimates. Invest your time in getting your teams high performing and flexible. As Michael Martin Hammer once said “The secret of success is not to foresee the future, but to build an organization that is able to prosper in any of the unforeseeable futures”.
      Good luck
      /Tomas

  • 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>