By: Alex Morgan, Agile Coach and Product Strategist — I’ve helped engineering and product teams adopt lightweight estimation practices across startups and enterprise organizations, guiding workshops, running planning sessions, and resolving the common friction that teams face when shifting from absolute to relative thinking.
Estimation conversations are where planning and reality part ways. "relative estimation" is a simple mental shift that turns that friction into clarity: instead of guessing how long a task will take in absolute units, teams compare items against one another. This article breaks down why relative estimation works, practical ways to run it, and how to make it a repeatable, trustworthy part of your delivery process.
What is relative estimation?
Relative estimation is a way of sizing work by comparing items to each other rather than predicting exact hours or days. Teams choose a reference point — a baseline story or size — and then judge other items as smaller, similar, or larger relative to that baseline. Common formats include story points, T-shirt sizes (XS–XL), or a simple ranking. The focus shifts from "How long will this take?" to "Is this bigger or smaller than that?" That shift reduces false precision and leverages humans’ natural ability to compare things.
Why relative estimation works
- Humans are good at comparison: Our brains struggle to estimate absolute time but can reliably say whether A is bigger than B. Relative estimation taps into that.
- Reduces bias and false precision: Estimating hours often leads to anchoring and defensive padding. When teams compare items, those cognitive traps lessen.
- Encourages shared understanding: The conversation that takes place when comparing items aligns the team on assumptions and risk.
- Scales with team velocity: Over time, velocity turns relative sizes into predictable throughput without requiring precise time estimates up front.
Popular relative estimation techniques
There are several proven techniques. Use one that fits your team culture and cadence.
Planning Poker
Each team member privately selects a card representing the perceived size (e.g., Fibonacci sequence, modified Fibonacci, or T-shirt sizes). Everyone reveals simultaneously and discusses differences until a consensus is reached. This prevents early anchoring and surfaces hidden assumptions.
T-shirt Sizing
Simple and fast: label tickets XS, S, M, L, XL. Ideal for early backlog grooming or when granular story points are unnecessary. T-shirt sizing is great when you want speed and a rough sense of relative scale.
Affinity Estimation (Grouping)
Put all items on a wall (physical or virtual) and rapidly group them by similarity in size. Once grouped, teams can assign relative sizes to each group. This method is especially efficient when sizing many small items quickly.
Bucket System
Create pre-defined buckets (1, 2, 3, 5, 8) and quickly place work into buckets. It blends speed with a controlled scale, reducing lengthy debates for every single item.
Step-by-step: Running an effective relative estimation session
- Prepare a clear backlog: Ensure stories are small enough to estimate—epics should be broken down.
- Choose a reference story: Pick one concrete story the team agrees on as a baseline (for example, “a simple login form” = 3 points).
- Explain the scale and rules: Whether using Fibonacci numbers or T-shirt sizes, make sure everyone understands what each size generally means.
- Estimate collaboratively: Use Planning Poker or affinity grouping. Encourage short justifications for outliers rather than long monologues.
- Record the consensus and assumptions: Add a one-line rationale to the ticket for future reference—this saves rework when ambiguity appears later.
- Review and calibrate: After a sprint or two, compare completed work to estimates and recalibrate the reference story or scale if necessary.
A practical example (anecdote)
On one product team I coached, the backlog was full of vague “build” tickets. Estimates in hours varied wildly between developers. We introduced relative estimation with an affinity mapping workshop: the team placed twenty backlog items on a virtual board and grouped them into three relative buckets. We picked a baseline story and labeled groups S, M, and L. In the following sprint, velocity stabilized and the team stopped arguing about hours. The discussions shifted to uncovering missing details and edge cases, which actually improved delivery predictability.
Common pitfalls and how to avoid them
- Using story points as performance metrics: Story points are meant to estimate complexity, not measure individual productivity. Use throughput, cycle time, or business outcomes for performance evaluation.
- Overfitting the scale: Don’t invent overly precise scales early on. A simple Fibonacci or T-shirt set is usually enough; complexity comes later if needed.
- Forgetting assumptions: If the team doesn’t document the key assumptions behind an estimate, the estimate loses its value. Add brief notes to tickets.
- Estimating unrefined work: If an item is unclear, the estimation discussion should reveal that. Break down or spike the work first instead of guessing.
Measuring success with relative estimation
How do you know your approach to relative estimation is working? Look for these signals:
- Stabilizing velocity: Over successive iterations, the number of relative-sized items completed per sprint becomes predictable.
- Shorter estimation meetings: As the team calibrates, estimation becomes faster and focused on uncertainty rather than size debates.
- Fewer re-estimates: When the team consistently completes work near its estimated size, confidence grows and planning improves.
- Better planning outcomes: More reliable releases, fewer rushed last-minute changes, and improved stakeholder trust.
Tools and remote-friendly practices
Many teams run relative estimation remotely with good results. Use simple tools to replicate the physical experience:
- Miro, Mural, or a shared whiteboard for affinity mapping.
- Built-in Planning Poker plugins for Jira, Azure DevOps, or Trello add-ons for card-based estimation.
- Keep cameras on when possible — quick gestures and expressions help resolve disagreements faster.
- Timebox discussions: if consensus isn’t reached in a few minutes, assign a small spike or split the story.
Integrating relative estimation into product planning
Relative estimation is most powerful when it's part of a broader planning workflow:
- Use it during backlog refinement to queue sprints with similar-sized work.
- Combine with value-based prioritization: pair relative size with business value to optimize for ROI.
- Align stakeholders by translating relative sizes into probable delivery windows using historical velocity.
When not to use relative estimation
Relative estimation shines for software development and ambiguous creative work, but it’s not always the right tool. If the work is a one-off with highly deterministic tasks (e.g., a known maintenance script with well-defined steps), absolute time estimates can be appropriate. Also, teams that need contractual deadlines tied to hours may need a hybrid approach: use relative estimation for internal planning, then derive absolute commitments through negotiation and buffers.
Real-world calibration tips
Calibration is the hidden art of relative estimation. A few practical tips:
- Keep a visible reference story: Store or pin a baseline ticket that everyone can view when sizing new items.
- Periodically re-select the baseline: As the codebase changes and team skills evolve, what used to be "M" may feel different; adjust proactively.
- Capture velocity trends: Track completed relative points over several iterations to translate future estimates into realistic delivery windows.
Frequently asked questions
How granular should stories be before estimating?
Ideally, each story should be small enough to be completed within one sprint. If a story is larger than the team’s biggest relative size, break it into smaller pieces or create a spike to reduce uncertainty.
Should testers, designers, and product owners be part of the estimation?
Yes. Diverse perspectives reveal hidden dependencies and non-development tasks (design reviews, QA integration). Including the whole cross-functional team leads to more accurate relative sizing.
Resources and exercises
Want to try a quick practice? Run a 30–45 minute affinity estimation session on your top ten backlog items. Use cards or a virtual board, pick a baseline, and group items. Debrief on what assumptions surfaced.
For a light diversion or demonstration of interactive play, see keywords. For more estimation tools and plugins, your team’s project board often has extensions that implement planning poker and affinity estimation directly.
Conclusion
relative estimation is a pragmatic, human-centered approach to sizing work that reduces false precision, improves team alignment, and yields better planning outcomes. It’s not a magic bullet—discipline, calibration, and good backlog hygiene are required—but with regular practice and clear baselines, teams move from guessing to predictable delivery. Start small, iterate on your scale, and treat every estimation session as an opportunity to clarify assumptions and reduce future rework.
About the author: I coach teams in pragmatic Agile techniques and help organizations translate uncertainty into reliable outcomes. If you want a workshop agenda or a checklist to run your first relative estimation session, reply and I’ll share a ready-to-use facilitator guide tailored to your team size and tooling.
