Time Keeps On Slipping, Slipping...

One debate I've constantly encountered working with teams is what unit of measurement is the best for estimating user stories. Some people use ideal days. Some people advocate for story points. In my opinion time-based estimates for stories have some considerable drawbacks when it comes to teams using them to estimate stories and determine the velocity for a sprint.

Before I go into the reasons why I have a bias against estimating in time units, I want to bring up that whether or not you use time, story points, relative mass effort, or no estimates, there is something that absolutely needs to be done: analyzing the stories as part of a backlog refinement session. Teams should absolutely sit down before working on stories and gather as much information as they need to understand the problem the solution should address. Teams need to answer the following:

• Do we have a shared understanding of what the value proposition to the customer might be?
• Do we understand what success for the solution looks like?
• Do we understand what tasks we need to perform to deliver the solution?

Only until the team has clarified those questions can any intelligent attempt be made to estimate what kind of time or effort is required to deliver this new great thing they are building.

So why not use time to give estimates instead of something more abstract like story points? 

Well, strictly speaking, we humans are truly terrible at predicting time. It's something called the Planning Fallacy. We tend to display optimism in our predictions as they relate to our ability to complete a task within a specific period of time and thus tend to underestimate. This is another reason we should estimate as a team...but that's a topic for another day.

So why would a team want to use time as a unit of estimation? I posit that it is because it's something we can all grasp and agree on. A day is 24 hours. An hour is 60 minutes. We can all wrap our heads around that and agree on what these units represent. Unless of course you happen to be pretty deep in a gravity well, such as a black hole, and are experiencing relativistic time dilation. Should you find yourself falling into a black hole then missing your sprint goal is probably the least of your problems.

But just because we can all objectively agree on what a unit of measurement represents doesn't necessarily mean it's the best unit of measurement.

Here's a little thought experiment I'd like to play with you. Suppose my "user story" is to take a trip to visit my parents. How would I put an estimate to that story? I could just go to Google Maps and put in the destination. Doing so I will get the result of 9 hours, which I can assure you is not the case. Experience tells me that 9 hours assumes nothing more than I'm driving at a constant speed with no interruptions.

Did I fail to mention that I have a wife and two teenagers traveling with me? I probably have should have mentioned that during backlog refinement. We will require stops for food and bathroom breaks. How long will those take? That depends on whether we bring lunch or stop at that roadside taco truck. Do we stop to eat or do we eat in the car? If we stop, how long will it take to be served? If we stop for a bio-break and my wife reports that the women's room is a biohazard disaster, how long will it take to find one that meets her satisfaction? These are some factors where we can directly influence time variances.

Now let's factor in all those external variables for which we can't account. Weather can force us to drive more slowly. Traffic congestion can bring us to a standstill. Road closures can force us to take detours. Accidents can bring the trip to a complete halt. That questionable taco could start tap dancing in my tummy.

So is giving a time estimate for my trip better than simply saying that I can subjectively complete this medium complexity task in my 16 waking hour timebox? If one of my goals in life is the reduce my personal muda (i.e. fretting over details), what approach should I take?

All said and done, it's well-nigh impossible to consistently and accurately predict the time it will take me to drive to my parents’ home. Emergent details that can radically alter the course of events arise as I drive, and the longer the drive, the more the likelihood I will encounter something that throws off that 9 hour estimate.

I could put a ton of effort into analyzing how external variables can affect that baseline of 9 hours, but why bother? I can say that a 500 drive through several urban centers is a medium complexity story. It might take me 9 hours to 12 hours to drive there depending on all kinds of facts that will only emerge once I am driving. Ergo, time is really a variable output dependent on the complexity of the work.

Hey! Aren’t story points an abstraction of subjective complexity to deliver something of value? Maybe we should cut straight to the chase and just use those? I need to achieve that value independent of external variables and using whatever methods are available to me.

So in the spirit of keeping things simple and reducing the work done, I advocate for using something other than time-based estimates. Feel free to agree or disagree and leave your comments below.

For a much more in-depth look at estimation you can't beat Mike Cohn's Agile Estimating and Planning.