Agile Estimation Techniques Explained
The number you write down is the least valuable part of estimation. The conversation that produces it is where the real work happens.
The insight most teams miss
Estimation is a team conversation disguised as a number
When a team estimates together, something important happens that has nothing to do with the final number. Assumptions surface. Risks appear. The person who was "going to take this ticket" explains their approach — and three colleagues spot things they missed. If that person is unavailable tomorrow, the team still has the context to keep moving. The number is a side-effect. The shared understanding is the product.
Surface risks early, when they are cheap to address
Expose hidden assumptions before they become costly surprises
Hear different approaches before committing to one
Build collective ownership so the team is resilient to change
Every technique below is a structure for having these conversations. The scale you choose matters far less than the quality of the discussion it triggers.
Decision guide
Which technique fits your team?
Use this table to quickly match your context to the right estimation approach. Each row links to a detailed explanation below.
| Technique | Scale | Best for | Precision | Learning curve |
|---|---|---|---|---|
| Fibonacci Story Points | 1, 2, 3, 5, 8, 13, 21 | Sprint planning, backlog grooming | Relative (abstract) | Moderate |
| T-Shirt Sizes | XS, S, M, L, XL | Roadmap estimation, early-stage sizing | Relative (abstract) | Low |
| Ideal Days | 1, 2, 3, 5, 10… | Teams transitioning from hours to relative sizing | Semi-concrete | Low |
| Hours | Free numeric | Fixed-scope contracts, client billing | Concrete (time) | Low |
Fibonacci Story Points
- Scale
- 1, 2, 3, 5, 8, 13, 21
- Best for
- Sprint planning, backlog grooming
- Precision
- Relative (abstract)
- Learning curve
- Moderate
T-Shirt Sizes
- Scale
- XS, S, M, L, XL
- Best for
- Roadmap estimation, early-stage sizing
- Precision
- Relative (abstract)
- Learning curve
- Low
Ideal Days
- Scale
- 1, 2, 3, 5, 10…
- Best for
- Teams transitioning from hours to relative sizing
- Precision
- Semi-concrete
- Learning curve
- Low
Hours
- Scale
- Free numeric
- Best for
- Fixed-scope contracts, client billing
- Precision
- Concrete (time)
- Learning curve
- Low
How it works
The estimation flow: from ticket to team alignment
Regardless of which scale you choose, the estimation process follows the same pattern. The technique changes the vocabulary; the conversation stays the same.
Introduce
The host presents a piece of work — what it is, why it matters, and any known constraints.
Discuss
The team asks questions. What problem are we really solving? What have we tried before? What could go wrong? This is where hidden assumptions surface.
Vote
Everyone submits their estimate simultaneously. Simultaneous voting prevents anchoring — no one is influenced by seeing a senior developer's number first.
Reveal & compare
Votes are shown at once. Quick consensus? Move on. Wide spread? You have just found the most valuable conversation on your backlog.
Converge
Outliers explain their reasoning. The team re-votes if needed. By the time you agree, everyone understands the work — not just the number.
Fibonacci story points
Fibonacci Estimation: precision decreases as size grows
The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) reflects a fundamental truth about software: as work gets larger, our ability to estimate precisely decreases. The growing gaps between numbers are a deliberate feature, not a flaw.
If something feels like a 6, the team must commit to either a 5 or an 8. That forced choice is where the real conversation starts. "What makes this a 5?" "What would push it to an 8?" These questions uncover complexity that a free-text estimate would gloss over.
Most teams also include a question mark ("I need more information") and an infinity symbol ("this is too big to estimate"). These are not failures — they are signals to pause and have a different conversation: What would we need to learn? How could we break this down?
Strengths
- Growing gaps force teams to discuss edge cases rather than splitting hairs between a 6 and a 7
- Abstract numbers discourage managers from converting points to hours
- The most widely used agile estimation scale — easy to find training, references, and tooling
- Enables velocity tracking and sprint capacity planning over time
Watch out for
- Stakeholders sometimes treat points as disguised hours — resist this firmly
- Point inflation can creep in if the team does not periodically recalibrate
- New team members need time to calibrate to the team's point scale
Use when:
Fibonacci story points work best for sprint planning and backlog grooming where the team needs a shared, abstract measure of relative complexity. They shine when you have a stable team that can build calibration over multiple sprints.
Avoid when:
Avoid Fibonacci when stakeholders insist on time-based answers, when the team is brand new and has no shared reference points, or when the work is so small that everything is a 1 or a 2.
T-shirt sizing
T-Shirt Sizing: fast, inclusive, and hard to over-think
Small, Medium, Large, Extra-Large. Everyone intuitively understands these categories, which makes T-shirt sizing the lowest-friction estimation technique available. There is no debate about whether something is a 5 or an 8 — it is either Medium or Large, and that simplicity is the point.
T-shirt sizing excels in early-stage planning where precise numbers are premature. When you are sizing an entire roadmap quarter or triaging a backlog of 50 items, you do not need Fibonacci-level granularity. You need to separate the small work from the large work quickly so you can plan capacity at a high level.
Strengths
- Anyone can participate — no agile training required
- Teams can size 20–30 items in a single session without fatigue
- Impossible to over-engineer — you cannot argue whether something is a Medium-Plus
- Natural fit for roadmap-level conversations with mixed audiences
Watch out for
- Cannot easily calculate velocity or sprint capacity
- Boundaries between sizes are subjective — one team's Large is another's Medium
- Not granular enough for sprint-level commitment planning
Use when:
T-shirt sizing is ideal for roadmap estimation, PI planning, or any context where you need fast relative sizing from a group that includes non-technical stakeholders.
Avoid when:
Avoid T-shirt sizing for sprint commitment planning where you need to forecast capacity, or when the work is well-enough understood that the team can give more precise relative estimates.
Ideal days
Ideal Days: a bridge between abstract and concrete
An ideal day is a full day of focused, uninterrupted work on a single task — no meetings, no Slack, no context-switching. When a team estimates "3 ideal days," they mean: if someone could work on this without distraction, it would take three days of focused effort.
Ideal days give teams a stepping stone from time-based thinking to relative estimation. The concept is concrete enough that developers can reason about it intuitively, but abstract enough (because ideal days are never calendar days) that it discourages false precision.
Strengths
- Developers naturally think in terms of "how long would this take me?"
- Excellent transition technique for teams moving away from hour-based estimation
- Simple to explain to stakeholders without agile training
Watch out for
- Stakeholders will confuse ideal days with calendar days — you will need to repeat the distinction constantly
- Estimates tend to reflect the estimator's personal speed rather than team capacity
- Still anchored to time, which makes it easier for managers to create unrealistic schedules
Use when:
Ideal days work well for teams transitioning from hours to relative sizing, or for teams where the concept of abstract story points feels too disconnected from reality.
Avoid when:
Avoid ideal days once the team is comfortable with abstract estimation — the time anchor creates more problems than it solves at that point.
Hours estimation
Hours: when the contract requires a number
Estimating in hours is the most concrete and most familiar technique — and the most dangerous if used without care. Every developer has been asked "how many hours will this take?" and every developer has learned the hard way that the answer is almost always wrong.
Despite its shortcomings, hour estimation exists for a reason. Fixed-price contracts, client billing, regulatory reporting, and budget approvals often require time-based estimates. When the business context demands hours, the goal is to produce the least-wrong number possible while preserving the team conversation that surfaces risk.
Strengths
- Everyone — from developers to CFOs — understands hours
- Often required for fixed-scope contracts, procurement, and billing
- Directly maps to cost calculations and budget forecasting
Watch out for
- Creates an illusion of precision that rarely survives contact with reality
- Estimates are easily treated as commitments — "you said 40 hours"
- Focuses on duration rather than complexity, risk, or unknowns
- Anchors the conversation to time rather than understanding
Use when:
Use hours when your business context requires it: client-facing estimates, fixed-price deliverables, regulatory reporting, or budget approval processes.
Avoid when:
Avoid hours for internal sprint planning. The false precision discourages the broad discussion that makes estimation valuable, and the time anchor creates accountability distortions.
#NoEstimates
#NoEstimates: what it actually means (and doesn't)
The #NoEstimates movement, popularised by Woody Zuill and Vasco Duarte, argues that traditional estimation often consumes time without delivering proportional value. The core insight is sound: if your team ships small, well-understood increments continuously, historical throughput (how many items you complete per week) becomes a better predictor than any estimate.
Teams that practise #NoEstimates well tend to do three things exceptionally: they break work into consistently small slices, they measure cycle time and throughput religiously, and they use historical data to forecast delivery ranges. These are genuinely good practices regardless of whether you formally estimate.
Where #NoEstimates struggles is in the assumption that all work can be sliced small enough to make estimation unnecessary. In practice, many teams face work that is genuinely uncertain — new integrations, unfamiliar domains, architectural changes — where the act of estimating together is the cheapest way to discover what the team does and does not understand.
Our take
We believe the best teams borrow from both worlds. Use throughput data for forecasting. Use estimation sessions for discovery and alignment. Skip estimation for well-understood, repeatable work. Estimate together when the work is uncertain enough that the conversation itself has value.
If your team leans #NoEstimates
- Break every item to a size your team can complete in 1–3 days
- Track throughput weekly — items completed, not points burned
- Use historical throughput to produce probabilistic forecasts ("we will complete 15–20 items by sprint end")
- Reserve estimation sessions for genuinely uncertain work where the team conversation has high discovery value
Common question
Should you estimate bugs? Probably not.
Most experienced agile teams do not estimate bugs, and for good reason. A bug is a defect in something you already built — estimating it implies the defect was planned work, which distorts your velocity and creates perverse incentives (larger bugs "earn" more points when fixed).
Instead, track bugs separately. Measure your bug fix rate as a health metric, not a velocity contributor. Reserve a percentage of sprint capacity for bug work (many teams use 10–20%) and let the team pull bugs based on severity rather than estimates.
All techniques, one platform
Every estimation technique — one collaborative session
Run Fibonacci planning poker, T-shirt sizing, ideal days, or hours estimation in a single real-time session. Ibis Flow captures the reasoning behind your estimates, syncs results to Jira, and builds a history your team can learn from.
Ready to estimate as a team?
Ibis Flow turns estimation into a fast, collaborative session — and captures the reasoning behind your estimates, not just the numbers. Real-time planning poker, Jira integration, and AI-powered insights.