(Or Why Guessing Effort Is Like Cleaning a Disaster Kitchen)

Estimation in Agile isn’t about predicting the future — it’s about creating a shared understanding of work. Whether you’re planning a sprint or sizing up your backlog, you’re not aiming for perfect accuracy. You’re trying to get close enough to make smart decisions as a team.

So how do we estimate? Broadly, you’ve got two camps:

• Absolute estimation: Estimating in time (hours/days).
• Relative estimation: Estimating by comparison (story points, T-shirt sizes, etc.).

Let’s break down both styles, where they shine, where they fail, and how you might blend them to suit your team.

Why Estimate at All?

Before diving into methods, it’s worth asking: why do we estimate?

Estimation helps Scrum teams:

• Understand and discuss complexity.
• Forecast how much work fits in a sprint.
• Communicate progress with stakeholders.
• Identify unknowns early.

Even when your guesses are rough, the conversation around estimates adds real value. Now let’s get into the how.

Absolute Estimation: The Stopwatch Method

Absolute estimation puts a time box on a task.
Example: “This bug fix should take about 2 hours.”

👍 When Absolute Estimation Works

• The task is simple and well-defined.
• You’ve done it before (and have solid data).
• You need to communicate timelines to people outside the team.

It’s like saying, “Boil pasta for 8 minutes.” Easy. Measurable. No surprises.

👎 When It Fails

• Work is vague, complex, or creative.
• Distractions, blockers, and context-switching aren’t factored in.
• It creates false confidence. Saying “3 hours” doesn’t make it true.

Example: You say “Dinner will take 20 minutes,” but you forgot to defrost the chicken, you’re out of garlic, and your kid just dumped yogurt on the dog. Sound familiar?

Relative Estimation: The Agile Way

Relative estimation compares tasks to each other instead of time.
Example: “This feels like a 3-pointer — easier than the 5-pointer we did last sprint, harder than that 1-pointer bug.”

It’s more like saying, “Cleaning this room is worse than doing dishes, but not as bad as tackling the garage.”

👍 Why Teams Love It

• It’s fast. No debating if something is 3 or 3.5 hours.
• It focuses on complexity and effort, not just time.
• It works across team members with different speeds.
• It sparks conversation. “Why is this a 5? What makes it hard?”

You’re not estimating in hours — you’re estimating in pain. And that’s often more useful.

👎 Where It Gets Tricky

• Stakeholders don’t always get it. “13 points? Cool… but how long is that?”
• Teams need a shared baseline. If your “5” is my “13,” the system falls apart.
• It can feel vague if not regularly calibrated.

Quick Example: Same Task, Two Approaches

Task: Build a login form

• Absolute: “That’ll take 3 hours.”
• Relative: “Compared to the password reset flow (a 5), this is simpler. Let’s call it a 2.”

See the shift? Relative estimation creates a comparison landscape. Absolute estimation assumes precision.

The Hybrid Reality: Estimate in Points, Plan in Time

Here’s what many high-functioning Scrum teams do:

• Estimate in relative units during sprint planning (story points, T-shirt sizes, etc.).
• Track historical velocity to see how many points they complete per sprint.
• Convert to time only when needed — like forecasting for leadership or syncing with external deadlines.

So internally, you think in “potatoes.” Externally, you translate to minutes.

Common Mistakes to Avoid

• Equating story points with hours. (A 5 is not always “5 hours.”)
• Ignoring the need for calibration. (Teams must align on what each point value represents.)
• Assuming estimation is a solo activity. (Estimates should reflect team input, not one person’s guess.)

Summary: Which Estimation Style Wins?

Honestly? Neither wins across the board. Each has its place. Use absolute estimation when predictability is high and external deadlines matter. Use relative estimation for sprint planning, velocity tracking, and collaborative thinking.

Here’s a quick reference:

Your Takeaway Checklist

✅ Does this task have clear, repeatable steps? Use absolute.
✅ Is the complexity uncertain or subjective? Go relative.
✅ Are you aligned on what a “3-pointer” means?
✅ Are you estimating as a team — not in silos?
Are you tracking how accurate your past estimates were?

Final thoughts

Estimates are guesses. Useful guesses, but still guesses. Don’t treat them like promises. Treat them like tools that help your team align, plan, and adapt.

Now go point those stories, size your T-shirts, and remember to leave a buffer for the mystery Zoom call. Because in Agile — as in life — the only thing you can estimate with certainty is that plans will change.

🔥If you liked this article, check out the next one where we demystify spikes and share the main differences between spikes and stories.

Written by

Simina F.

| howtobecomeapm.com – Author |