Agile Planning: ‘Ideal Day’ – User Story Estimation

I 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 aren’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.