A Matter Of Time - Guesswork, Points And Yesterday's Weather

Ed carefully tiptoes towards Karl's desk. "Hey Karl", he cheerily announces: "I still need this time estimation for the Globster project!".

"Yea, right... That was the Irish Coffee feature for their coffee machines at the management offices, wasn't it? I just have to read some specs to figure out what I have to do - give me two days."

Ed hesitates for a second: "So, you tell me you need two days to give me an estimation?"

"Yeah, so?" Karl shoots Ed an inquiring look. He really hates time estimations. They always seem to come back at you. Mostly when you want to leave work in the evening. Looking straight into Ed's face Karl knows what's expected of him: "Ok, let's just say it takes 5 days".

Leaving Karl's desk Ed heads straight for the coffee machine. What on earth is the developer's problem with time estimations? Getting the coffee machine to deliver Irish Coffee can't be that hard, after all... and it would be a nice addition for their own machine. Somebody has to do the testing.

"Hey Ed, good that I meet you. I've got Mr. Globster on hold, how long will the changes for the project take?" - "Oh, hey Dave, Karl said it's about 5 days..." - "Thanks, Ed!"

"Mr. Globster? Yes, the new software will be ready at Friday, no problem. A manager password and taxi service will be included."

Just a matter of time

On software projects there's not just time. There's real time and ideal time (and, of course, lunchtime - if there's enough real time left). Ideal time is what you get when you ask a developer to "estimate" a task (though if you ask a developer she will probably call it guessing, not estimating). Real time is, well, the time that it takes.

When Karl says the Irish Coffee feature will take 5 days, he means it could very well take about 5 days (or 10, remember he didn't read the spec yet) if he somehow manages to work uninterrupted for 5 days without introducing subtle bugs. See why it's called ideal?

Somehow the ideal time finds it's way to Dave. In the heat of the battle, Dave forgets what Karl told him about ideal time and real time four times in the past two weeks: they're not equal. Dave sets an artificial deadline that is based on ideal time, which will eventually make the cleaning lady wonder uneasily about the bite marks in Karl's desk.

"Time is an illusion, lunchtime doubly so." Douglas Noel Adams

Why does Karl hate to guess times? Well, he doesn't like it if he needs longer for a task then he guessed. He really hates it. That's why you can choose his reaction to the ideal time deadline situation from this list:

• Overcommitment
  But this time I'll do it in 5 days! really!
  
• Undercommitment
  If I guess a lot too much, I feel better if I'm wrong. And perhaps my lunch will be still warm.


• Artificial Pressure
  I guessed 5 days and Dave already promised it to Mr. Globster. So let's not do this refactoring now.


• Demotivation
  Being wrong makes me feel bad. Especially if Dave is involved somehow.


• Problems with communication to product management
  "But you said you'll do it in 5 days, now it already took 10!"
  "But I said it's ideal time!"
  "Than tell us the actual time it will take the next time!"
  "But I can't do that"
  ...
  

Points vs. Hours

But what can you do? You can explain to the developers that they have to accept that ideal time has nothing to do with real time and that they should not worry too much about the correctness of single guesses and you could explain to product management that there are different time estimations (some in ideal time and some in real time) and make them actually remember all this stuff when they talk to the customer the next time.

You could also try to give free copies of "Time Thief" to your developers and wait to see if they start slicing time and getting things done before they even started.

Or you can use points instead of ideal time. The idea of story points is an agile practice to help companies keep the cost for replacing bite marks in tables to a minimum. It is closely related to the project velocity.

"Why are our days numbered and not, say, lettered." Woody Allen

You guess a rough size for every task in the next iteration. The task size is measured in points. At the end of the iteration you can sum up all the points and see how many points the team managed to complete in the iteration. Using this metric on the team level averages out some of the statistical blur. This way you get a good impression how many points can be finished by the team per time unit (we don't need real and ideal time any more - it's just time now (at least until lunchtime, of course)). In the next iteration you just schedule the number of points you finished in the last iteration. Yesterday's weather.

So how is this different from measuring ideal time in hours and summing up ideal time at the end of the iteration to get an impression of "ideal time per real time unit"? It isn't. Well, not technically. But psychologically. Do you feel bad finishing 3 points in two weeks? How about "3 days work" in two weeks? Can you really let go of our strange human affection to time when you talk about "ideal time"?

So what?

If the alternatives are to try to break people's affection to time and nit-pick about nerdy concepts or communicate my intent distinctly I prefer the latter. That way I have more time to write code.

See also: Do you understand XP?