How long will that take? (a How To guide to estimating)

No matter what your role in business or technology, a question we all hear is: “How long will that take?” With anything, and with software development in particular, this is a difficult question to answer because, well… It depends. Unfortunately, that’s not usually an answer we can give. Thankfully, there are some ways that we can take our usual stab-in-the-dark estimate and apply a process to come out with a more accurate (or at least less inaccurate) estimate of how long our work will take.

Step 1: Break things down into subtasks. You wouldn’t know off the top of your head how long it would take you to paint a house, so it’s reasonable that you also wouldn’t know off the top of your head how long it will take you to build that website/app/widget. The first step to an accurate estimate is to break down your work into its pieces, which is known as a Work Breakdown Structure (WBS). In our house-painting example, we would break the work down into the north wall, east wall, south wall, and west wall, and then break the work down for each wall: tape around the window & door frames, prime the frames, let the paint dry, paint the frames, let the paint dry, remove the tape, tape the edges of the frames, prime the wall, let the paint dry, paint the wall, let the paint dry, remove the tape.

Step 2: Estimate each task’s best, worst, & most likely estimate. The “it depends” part of estimating is mostly “it depends on what goes wrong.” When we estimate a task with just a single number, we almost always are estimating the best case scenario (which is why we end up always going over estimate). By providing three estimates for each task, we have to think through what could go wrong, which immediately makes our estimate more accurate. Now, if you’ve never done a particular type of task before, then coming up with one estimate is difficult, not to mention three. In that situation, you have a few choices for how you do your estimates:

  • Do a small prototype of the work and see how long it takes you, then scale the amount of time to the size of the actual task. In our house-painting example, this could be painting a small section of wall, timing how long it takes, then multiplying that by how much bigger the entire wall is.
  • Ask friends/colleagues who have done the work before how long it usually takes them, then add some for your learning curve.
  • Compare the size of the task to other work that you’ve done, then scale the amount of time to the size of this task. Again, in our example, this could be that you’ve never painted a house, but you have washed a car, and the surface area of your car is about the same as one of your walls. So, assume that the painting of that much wall will take about the same amount of time as the washing of that much area, because the tasks feel similar.

Step 3: Compare your estimates to someone else’s. Agile software development has this step built into itself, where everyone estimates a story during the sprint planning meeting and then discusses what went into their estimate. If you’re not using Agile, it’s important that you still do this step of comparing estimates, because having several people think about the same task is always going to come out with a more accurate estimate than one person estimating alone.

Step 4: Calculate the expected time & confidence level. Using the Project Evaluation & Review Technique (PERT), calculate the Expected Case for your tasks and the Confidence Level:

  • Expected Case = (Best Case + 4*Most Likely Case + Worst Case)/6
  • Confidence Level = (Worst Case – Best Case)/6

The Expected Case that you calculate is what you want to use as your official estimate, and the confidence levels will give you an idea of how likely you actually are to finish in the estimated amount of time. As with anything, estimating is a learned skill and the more you do it (and reflect on the accuracy of your estimates), the better you’ll get at it.

Questions/Comments? Leave a comment below with where you’re stumped or what you’ve found to work well on your team.

Torrie Adams