There’s a very funny response to a question on Quora doing the rounds at the moment.  The question is “Why are software development task estimations regularly off by a factor of 2-3?”

The response (go ahead and read it) makes an analogy to hiking from San Francisco to Los Angeles to visit friends, underestimating the distance, terrain and rate of progress as well as encountering a number of impediments like the weather, colds, blisters and so forth.  It’s a really good read.

It was mentioned on the Australian Alt.Net mailing list, this week and followed up with the question of “so what do we learn from it?”

Two simple lessons come to mind.

Lesson 1: It takes time to produce a reasonable estimate

On any reasonable project don’t expect to be accurate if your estimate takes you less than 5 minutes to arrive at.  In the example, it’s pretty obvious that little time was spent coming up with the estimate for how long the hike might take.  Once they’d decided they were going to hike, taking time to estimate how long it would take was just stealing time from actually hiking!

As developers, we allow ourselves to do this all the time.  “I like to write code, I don’t like to estimate. If I get the estimate done quick then I can get back to doing what I like.”

Stop it.  You’re only storing up pain for yourself down the track.

Lesson 2: Think about what might slow you down

When you estimate think about what might slow you down.  Very few teams do this but it’s critical if you want to be more realistic about how long something will take.

Most developers estimate with the same approach that they test their own code.  They only consider the happy path.

You can hear them in their heads saying “It takes this long to do that. And that long to do that. And … then put it all together and the estimate is X months!!”.

Very few developers then say, “so the baseline is X months.  Now what is likely to slow us down?”.  Yet there are so many things that can do just that.

Want a basic list? How about the following:

  • Have you done anything like this before?  How vague are the requirements you have at the time of estimating?
  • How well do you know the technology you’re using?  Or the design and techniques you’ll be implementing with?
  • How well do you know the people on your team? Are you all co-located? Can you communicate easily?
  • Does your team have all the skills you need to get the job done or will you have to rely on other’s being available?
  • How well do we know the problem you’re being asked to solve?
  • How well can you communicate with your customer(s)? How available will they be?
  • How bad are the worst people on your team and how much will they slow everyone down?
  • How’s team morale? Are people likely to leave mid project and take a whole lot of knowledge with them? How long would it take to replace them and get them up to speed?
  • How sucky is the code you’re working on?
  • How likely is it that people on the team will get pulled off on to other work? And how often?
  • If you’re estimating will you be doing the work? Or are you estimating on behalf of someone else without involving them?

That’s a starting list of things all teams should consider when estimating and all of those items should be used to take your “happy path” estimate and adjust it from there.

 

So next time you need to estimate something, keep these two simple lessons in mind and good luck!