Estimating is a dangerous business. Projects become unprofitable, people get fired and developers rack up stress and work-related injuries because of inaccurate estimations. Still, the software business relies on it, budgets are planned by it and people get hired because of it. And on top of it all, there’s no class in Computer Science 101 that tells you how to do it.

After some years of trial and going through many a book on the subject, I come to that there’s no way of accurately giving a fool-proof estimate. Estimates are simply a way of predicting the future, which is impossible. In addition, every estimate will fail during changes to scope.

However, I’ve found a way to deliver estimates in a somewhat reliable form. Note that this is up-front estimating. Not re-estimation:

  1. Understand the domain: Know what you’re estimating. If you don’t know, ask somebody who do know. Don’t trust a document alone!
  2. Never estimate alone: Pair up with someone, give them a run-through of what’s being estimated and start working.
  3. Task it up: Set up a list of tasks that needs to be done. Avoid going into details, but keep it “just enough”.
  4. Estimate the pieces: Estimate each task on the list. If possible, stick to “working days” estimation. Personally I use this scale: 1/2, 1, 2, 3, 5 days. No task should be estimated for more than a week. In that case, break up the task even more.
  5. Discuss differences: If you and your partner come to different conclusions, discuss why and listen to each others arguments. Reestimate.
  6. Increase the estimate if in doubt: “it takes one or two days” means two days.
  7. High-level estimate: Summarize the number of estimated days. How do you feel about this sum? Too high? Too low? Adjust the estimate to a “high-level estimate”.
  8. [Optional] Estimate uncertainty: If the features are a bit sketchy or are prone to changes, add an estimated uncertainty rate. Do some “what ifs…” of what could happen and estimate the increase (or decrease) in days. This can again be calculated to percentage value. I’ve delivered estimates stating “the estimates have a 40% uncertainty range if the following situations occur:…”

Conquering some shout-outs:

  • “Estimating in days isn’t accurate enough. We need this estimation in hours!”
    • Sure, no problem. A normal working day is 7.5 hrs in Norway, 8 hrs in the US. Multiply the number of days with the number of hours of a day and I give you estimations to the hour. Besides, can you honestly differentiate an estimate of 75 hrs from 80 hrs?
  • “Estimating in days leaves too much inaccuracy. We cannot plan with this!”
    • So, estimating in hours increase accuracy? Not really. I can better understand how much work I perform during a day than in hours. Besides, the larger the unit the more accurate my estimates become. If the opposite, wouldn’t it be better do deliver the estimate in seconds?
  • “Our planning division spent much money writing this requirement document. And now you say you want to talk to them directly?”
    • Here’s a news flash for you: VERBAL COMMUNICATION OUTPERFORMS WRITTEN DOCUMENTATION WHEN IT COMES TO UNDERSTANDING! The ability to ask questions and get them answered is tremendously more important than writing a document. In addition, maybe the questions from the developers triggers a situation the planning division hadn’t thought of?
  • “We don’t want you to involve anyone else for this estimation. Just give us a number.”
    • Yes, stealing another developer for 30 minutes means 30 minutes less work done during that day. But what happens if you mis-estimate because you missed something? The risk suddenly increase a lot when the business starts budgeting solely on your estimate alone. And that will be far more costly.
  • “You estimated it to take 40 hours. It’s been two weeks, why aren’t you done yet?”
    • Estimations ARE NOT commitments! They’re best guesses. Estimates must be re-estimated in the course of development. In addition, 40 hours of estimated work does not mean one calendar week. It means working on a task continously for 40 hours. However, if you need to eat, stretch, answer some mails, browse, do another project or become sick, you will NOT create 40 hours of software in a week! Don’t mistake an estimate for calendar time.
  • “You estimated this to be 40 hours of work, but now you say it will take you 80 hours? That’s outrageous!”
    • Some people believe the estimate will always be accurate. But changes do happen. Things that weren’t thought of tend to appear. Don’t fight the estimate, adjust to it. If the task was budgeted for 40 hours, but it now takes 80 hours, adjust the scope to make it 40 hours. Sometimes it’s more profitable to cancel the feature all together. This is the power of re-estimating.