Why Agile Estimation Sucks

When your attention goes to numbers, you’re missing the point

It’s 08:45; Ivar, the Product Owner of Team Jorvik, opens the computer and quickly scans the Product Backlog. He shuffles some items as the backlog refinement is about to begin. At 08:57, Ivar starts the call; he is a bit tense because the last session was anything but pleasant. It’s 09:03, and Björn joins. They talk about random things for a couple of minutes until the rest of the team arrives. Already annoyed by the delay, Ivar gets even more worried because no one comes. Finally, at 09:14, everyone joins, and the session begins.

Ivar: “Guys! Today, we’ve got several items to refine. But don’t worry about some of them; we may only start working in four or six months, but I need your estimate.”

Harold, clearly irritated, interrupts Ivar: “Sorry! We have a lot to take care of right now, and you want to bug us about things we won’t be implementing in the upcoming months. Please, let’s focus!”

Ragnar: “Plus one!”

Björn: “Plus two!”

Ivar: “Well, I understand you’re busy, but we’ve got to talk about these things sooner or later. But OK, let’s focus on what’s critical. Our service desk team is overloaded, and they can no longer handle their workload. I thought about implementing a chatbot and solving their pain. How complex would that be?”

Björn, Ragnar, and Harold engage in a deep mysterious technical conversation. After 10 minutes, Ivar, totally lost, interrupts them: “Hey Guys! Let’s stop this tech talk! I want just a rough estimate; nothing else!”

Björn: “How am I supposed to estimate if I don’t know what the implementation would look like?”

Harold supports Björn and starts sharing his screen, and says, “Folks! I’ve done something similar, have a look at this material here. It’s pure gold! It’s already on GitHub! I can share it with you.”

Ivar is furious. The last meeting went exactly the same. The team didn’t estimate anything until they understood precisely how to implement the solution. Disturbed, Ivar says, “Dudes! I want to know how complex this bullshit is!!! Sorry, I mean chatbot. Is it simpler or more complex than the search we implemented last month? I need to know the Story Points for it.”

“EASIER!” Ragnar, Björn, and Harold almost shouted at the same time.

Ragnar: “That search was a pain in the ###. It sucked the soul out of me. No way this chatbot is harder than that, but I think it’s more complex than our recommendation engine.”

Ivar: “That’s it! It must be a fucking 13, then! The search was 21, and recommendation 8! That’s the only option!”

Does this scenario ring a bell to you?

Let me walk you through why estimating is frequently a nightmare for Agile teams. Ultimately, I will share what helps me overcome the estimates traps.

When Estimating Becomes a Nightmare

I often receive one of the following questions:

• How can I improve my estimation process?
• Which Agile estimation techniques should I use to estimate?
• Should I estimate by working days or complexity?

In my opinion, any of these questions will lead to a pointless answer. When our attention goes to estimating, we miss the point. You can improve your agile estimation technique or use a more precise one, but you are bound to stumble upon the same problems if your mindset isn’t Agile. Here are some common problems when estimates are misinterpreted:

• Developers are unwilling to estimate because they don’t want to give imprecise estimates.
• Stakeholders will hold you accountable when the team misses an estimate.
• You will fail to deliver all promised story points at the end of your Sprints.

“To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.” — Chinese proverb

The scenario described at the beginning of this post reflects many refinement sessions I’ve observed. It’s an unstructured meeting that leads to frustration and misses the mark.

The goal of refinement is to gain clarity on the problem, not on the solution.

At the end of refinements, Agile teams should understand which problem they are supposed to solve and why that is important. Unfortunately, most refinements focus on estimating solutions and sharpening requirements.

One of the biggest traps of estimates is how people interpret this word. Although I am not a native English speaker, I am pretty convinced the words “estimate” and “commitment” are different. Curiously, Product Owners and Stakeholders tend to hold developers accountable for estimates. For me, this is a massive problem; it leaves developers without any other option but to be hyper careful with their estimates.

Escaping from the Estimation Circus

A precise prediction of how much effort developers need to invest in order to implement solutions is impossible given all complexity behind software development. The critical part of succeeding with estimates is to accept their nature: they are IMPRECISE.

Don’t waste your energy trying to be precise. Focus on creating clarity.

Doesn’t matter which estimation technique you use, the goal is to build a shared understanding with the team. Do all developers see the world in the same way? If they don’t, you’re not ready to move on. My favorite estimation technique is planning poker. It’s easy to understand, is dynamic, and yields knowledge.

For example, when a developer estimates something as a 3 and another developer as an 8, they obviously see the world through different lenses. When they share the reason behind their estimation, the team benefits from different perspectives, which helps them progress. They may ultimately agree on a 3, 5, or 8, but honestly, I don’t care which number they pick. As Product Leader, I only care about whether the team shares the same problem understanding or not; the estimate itself is irrelevant to me.

“There is nothing so useless as doing efficiently that which should not be done at all.” — Peter Drucker

I like one analogy I read the other day: We should stop estimating and start forecasting. Consider the weatherman. If you look at the weather forecast for a week from now, you can be certain it will change as the day passes. The reason is simple: as the weatherman gets more information, he adapts the forecast according to the acquired knowledge. That’s why I encourage people to re-estimate.

Final Thoughts

After more than a decade of working with Agile teams, I learned to be indifferent to estimates. I only worry about the understanding the team builds, not the numbers they assign to each item in the Product Backlog (also known as scrum artifact).

Here’s what I think on how to do an agile estimation in  a sustainable way:

1. Set the stage: The Product Owner explains the problem behind the User Story and why solving it is important.
2. Questions: Developers ask questions to understand the problem and what specifically should be solved.
3. Clarity: The Product Owner clarifies the open points with developers.
4. Estimate: Developers estimate the complexity of solving the problem.

This process should take no more than ten minutes. If it takes longer, it’s a sign that the team is already evaluating the implementation or thinking about effort instead of complexity.

One of the critical aspects of agility is embracing the unknown. Estimates are dangerous because they often get in the way of being Agile. When we focus on actions to cover our insecurities, we fall into traditional patterns.

Truly Agile teams speed up their learning time to create value sooner. They don’t get attached to a process.