Home > Agile, Scrum > Agile Planning: ‘Ideal Day’ – User Story Estimation

Agile Planning: ‘Ideal Day’ – User Story Estimation

USI don’t like Story Point estimating.  There I said it.  I know many have had success with Story Point estimating, and the Scrum guru Mike Cohn advocates it in his books/etc.  I have just found it to be too abstract, and difficult for developers (and myself) to grasp when starting out using Agile techniques.

In my experience, when developers/engineers/etc. are asked to estimate in hours (which is very much the norm in software), they rulersaren’t really thinking in hours.  Truth be told, I don’t think many actually think in hour blocks when estimating, but instead think in terms of ‘days of work’ or partial days of work.  Here’s an example of what a developer is thinking when giving an estimate:  “Hmm.. I think this task should take me about a day, maybe day and half to complete, so lets make it 8*1.5 = 12 hours”  Tell me you don’t do that?  There wasn’t any self talk on thinking part one of the task would take 2 hours, part two, 6 hours, etc. but rather they would ‘chunk’ their time into days.

So in comes Story point estimating.  We don’t want to be estimating User Stories from a calendar time perspective, but instead relatively against each other.  This allows for quick estimates that give size, but not ‘commitment’ to time which is what most developers feel an estimate is. Hour estimates come during User Story decomposition, part of Sprint planning.  Unfortunately, how do you define one Story Point?  What is your logical point of reference?

This is where the ‘Ideal Day’ metric works better for me.  This metric was shared with me by Pete Carroll and is really an abstraction of the number of hours you would normally expect a developer to be productive during a typical day, subtracting time for meetings, bathroom breaks, etc. This will vary from organization to organization, but has a large benefit over Story Point Estimation IMHO.  Mainly it is the default metric the developers are already thinking in as I eluded to above.  There isn’t any translation in their head, no trying to define an ambiguous metric.  Instead it’s more gut feel that is natural to all developers with some experience while still allowing for the relative estimating of User Stories to take place. All Ideal Day estimates should be in round numbers, (ie 1,2,3. not 1.5, 2.34, etc).

Trick here is to realize the Ideal Day metric is still an abstraction of time estimates.  We don’t plan off the Ideal Day on a timeline, but instead use team velocity matched with Ideal Days to equate to time-lining User Stories from a high level.  The Velocity metric will help even out the group estimation variance just like with Story points, but it feels so much more natural to the team.

Next up in this series, decomposing user story tips.

About these ads
  1. May 11, 2011 at 6:21 am | #1

    I think you are spot on. Story points are not intuitive and are difficult to teach. However many of the mechanisms for decomposing tasks and calculating velocity can be used in other estimation units.

    I would be careful using the term ideal hours or ideal days. That can also be confusing when you start talking x ideal hours per hour. I generally rename it “effort” but ensure everyone know that effort=hours/days.

    I put up a similar post which also included adding a staff overhead factor when converting estimates to duration. http://theagiledirector.com/content/estimating-duration

    • May 12, 2011 at 6:37 am | #2

      Evan: Thanks for the feedback and link to your post. I agree that the terms ‘ideal days/hours’ can be tricky to manage.

  1. December 1, 2013 at 1:14 pm | #1

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

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: