How To Make Precise Estimates in Software Development

How long time does it take to get to work? Don’t answer yet. We’ll get back to this question in a second.

Some may say that you’ll never accurately estimate anything. You’ll never get any better at estimating. New things always pop up to invalidate your previous estimates, so what good is it?

Let me tell you, it’s a lie. You can learn how to provide good-enough estimates.

Though, it’s true that more often than not, estimates are just wild guesses in disguise.

Estimates should be based on (real) expertise.

My advice is, to hold back on providing estimates for tasks in domain areas and technologies that you don’t have direct, hands-on experience with. Guessing estimates without the necessary expertise leads to project setbacks and progress is hard — if not impossible — to report on.

Even senior developers haven’t tried everything, and cannot reliably estimate tasks which they don’t have hands-on experience with.

It all comes down to experience. While you may never estimate a task 100% accurately, you can still get very close.

Remember, estimates are approximations. Thinking otherwise would be delusional.

If you have a lot of experience, that is, you have actually done something before, in the same or appropriately similar context, then you’ll likely come up with useful estimates.

Imagine traveling from home to work.

How long does it take? You’ve done it before. Many times. Some days, probably even multiple times. You know exactly how far the distance is. You know which means of transportation is the most effective, at certain times of the day.

You know exactly which factors that may affect your travel time. You even know the combinatory factors that may have cascading effects–is the train 10 minutes late? Well, say goodbye to the connecting bus that you could normally reach just in time. You know the impact of leaving 10 minutes early, or late. Even your mood that morning may play a role in how long time it’ll take, and you know that.

Try to answer this.

How long time does it take for you to travel from home to work on a Tuesday morning, leaving at 06:30 by car?

This probably had more detail than your average User Story.

Taking it a step further. Can you segment the route to your work? Where are the areas prone to congestion? And which parts are typically smoother? What’s the impact of not arriving on time? How about arriving a bit earlier than usual? I bet you know the answer to those questions as well.

It is possible to make precise estimates.

You see, it is possible to come up with a close approximation of how long time a task will take to finish. It’s even possible to think a bit ahead and consider the impact of making it on the estimated time or not.

You need to stop. Think it through. Segment. Visualize. Anticipate, and combine.

What’s stopping you from applying the same rigidness to estimating development tasks?

Well, I know. Stop, think it through, segment, visualize, anticipate, and combine isn’t exactly a memorable approach.

It might be operational, but you’d quickly forget a step or two.

When reading articles and books on software development, we’re repeatedly told how bad people are at estimating. That, you’ll never be any good at it, and attempting is a fool’s errand.

I don’t think that’s the case. Fundamentally, we’re lacking estimation guidelines. Guidelines that are simple enough to be operational. Guidelines that are easy to remember, yet versatile.

Ask yourself:

• Have I done this before, in this exact or appropriately similar context?
• Have I implemented technically similar solutions?
• Can I draw on anyone’s earlier experience doing this — do I know how to reach these people?

These three questions are a pretty good start. Easy enough to be memorable, and if you’re being honest, then you will also increase your estimates’ precision.

If you answer “no” to any of these, then there’s a good chance whatever you come up with is a guesstimate at best, and entirely misleading at worst.