Before you clicked “buy” on your last Amazon purchase, you checked when the product would be in your hands.

When you hired a plumber to repair your sink, you asked how long it would take until you could wash dishes again.

And when you ordered an Uber after that meeting last year, the app told you how long you’d be standing out front before the car arrived for you to quietly slip away.

Having an idea of when we’re going to receive or accomplish something is important. We crave it; sometimes for practical reasons – will I get my order in time for the wedding? – and often for emotional reassurance – how long will I have to feel like this??

Software development projects are no stranger to estimations, which is why we have an Estimations workshop in our Agile-as-a-Service program.

But believe it or not, some teams don’t do estimations at all.

Why on earth not?

If you’re on one of these teams, you might be asking, “Why are estimations so great, anyway?”

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.

Adapt

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.

Learn

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.

What’s behind an amazingly effective Agile Scrum?

Well, it all fits on our free one-page checklist. Find out if your team is ready to implement the most popular version of Agile, today.

Your first name

Your email address

YES! Email me a copy of the checklist.

YES! Keep learning about Agile: receive an Agile mini-course, occasional info about our other resources & programs for Agile, and monthly new blog articles.

Download Forms: Privacy notice

You can opt-out again at any time. We only use your email details to send you emails, not for personalized ads. To send you emails, including the download you’ve requested, the information you provide will be transferred to MailChimp for processing in accordance with their Privacy Policy and Terms. Read softsolutions’ full privacy policy.