Software Estimates vs Actuals: Don’t Make This Mistake!

18 May, 2017

#WhyShaiWhy [Videos] Agile Get Started with Agile Software







Why on earth not?


Let’s answer both of these questions!

Why are people scared to estimate?

A common reason why this becomes a touchy subject for participants of our workshop is because people are worried about the accuracy of their estimates vs the actual time they’ll spend.

Too worried, if I may say so.

But I can’t really speak for the teams who don’t do estimates, nor can I discuss plenty of reasons why because as you know, I’m a huge estimation fan. (Remember Wideband Delphi?)

Instead, let’s learn why estimations are useful in Agile and how to use them properly, with no fear and no pressure.

Agile and estimations

Here’s a snippet of the Agile process:

  1. We take a huge project and slice it into really thin pieces.
  2. Then we take each slice and estimate how much work is needed to get this piece of the project completed. (By the way, we call these slices User Stories. It’s just a fancy Agile term. You can call it whatever you want.)
  3. Once an estimate has been given, our business colleagues can now take a look at it, do a Cost-Benefit analysis, and assign its priority on the long queue of slices we have on our plate.
  4. When a User Story is approved, we then pass it back to our developers so they can begin working their magic on it.
  5. Here comes the scary part: We then ask developers to log the actual number of hours they spent working on a User Story. So now, our business colleagues and everyone involved can see a comparison of the estimate vs actual hours.

Whenever we get into this part of the workshop, an extremely common question is

What if I go over my estimate?

We hear this concern from developers, testers, and anyone who’s going to contribute effort to the project.

Wipe that sweat off your face

Breathe easy, bud, for that is a legitimate worry. Perfectly understandable.

A whole plethora of things out there are beyond our control and we can only anticipate so much. To get an accurate estimate every single time is an impossibility! Coming up with a wrong number is part of learning how to get better at estimations.

It’s an experience.

In Agile, aiming for the exact number is never the goal. It’s called “estimate”, for goodness sake!

If it’s okay to miscalculate, then why would anyone be too worried?

There’s this misconception that estimation is a performance measure. Like your boss can and should determine your awesome-ness based on your ability to size things up.

That is pure crazy talk!

This puts unnecessary pressure on your people. If a developer is failing to meet his given estimated time, he shouldn’t beat himself up just to reach it.

I understand that we want accurate estimates because we have a plan to follow: a carefully thought-out plan. We have resources to allocate, a laundry list of features to build, people to please, etc etc. All these things could get affected when there’s a delay on a single deliverable.


Plans are like living creatures—they change. If you want a successful project, the plans you laid out have to evolve. They have to adapt to changes. While an estimation is just that—an estimate, a rough calculation, an approximate judgment. The actual is always the other side of the coin.


If it took you 40 hours of work on a User Story, then that’s the amount of time it needed. It was always going to take that much, we just estimated wrong. The next time a similar story comes up, you’ll know for sure that 13 is far from enough.

The most important use for estimates is not as performance measures, but as learning tools for future estimations. If your team always under-estimates a certain type of job, then the problem is not with how they work, it’s with how they’re learning.

(Are you doing retrospectives?)

Estimation accuracy doesn’t define us as software engineers

Delivering value and getting high-quality code out the door is our primary objective. We really shouldn’t be too worried about the accuracy of our estimates vs actual time. It’s nice to hit the right numbers but remember, we can only get better with practice. Never perfect. That’s why estimations are not appropriate to be used for performance management.

We make mistakes. And it is through our mistakes that we learn and improve. Which is why I love Agile estimations so much! You’ll never run out of opportunities to grow.

#WhyShaiWhy engagement request


What’s behind an amazingly effective Agile Scrum?


YES! Email me a copy of the checklist.


Download Forms: Privacy notice


3 thoughts on “Software Estimates vs Actuals: Don’t Make This Mistake!

Leave a Reply to Shai Shandil Cancel reply

%d bloggers like this: