Estimation methods at a glance

1 · Basics

Estimates serve three purposes: predictability, prioritisation and – often underrated – shared understanding. When two people rate the same story completely differently, they usually have different things in mind. That discussion is the real value of an estimation session.

Agile teams mostly estimate in story points: a unitless, relative measure. People are bad at predicting absolute durations, but good at ranking things relative to each other. "About 8 points" is therefore a good estimate – "6.25 hours" pretends a precision that simply doesn't exist early in a project.

2 · The Fibonacci scale

Most decks use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21 …) or its modified variant (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). The growing gaps reflect growing uncertainty: whether something is a 2 or a 3 is worth discussing – whether it's a 20 or a 21 is not. Values from 13 upwards are less an estimate than a diagnosis: the story is too big and should be split.

Two special cards complete the deck: ? ("I'm missing information" – often the trigger for a spike) and ☕ ("break, please"). Both are legitimate, important answers.

3 · Planning poker – the classic

Everyone estimates simultaneously and hidden – that neutralises the anchoring effect (whoever hears a number first estimates close to it) and stops the loudest or most senior person from dominating the round.

How it works

1. Present the story and clarify questions – no numbers yet.
2. Pick hidden: all estimators choose a card at the same time.
3. Reveal together, only once everyone has picked.
4. Let the outliers speak: highest and lowest card briefly explain their view.
5. Estimate again – after the discussion the team usually converges within one or two rounds.
6. Record the value – with BESTIMATE automatically in the round history.

Ideal for sprint refinements with 3–9 estimators and a handful of stories. Unsuitable for 60 untouched backlog items – that's what the bucket system and magic estimation are for.

4 · T-shirt sizing

You estimate in sizes instead of numbers: XS to XXL. Nobody can do maths with letters – no averages, no false precision. That makes it ideal for early phases: roadmaps, epics, stakeholder discussions.

5 · For large backlogs

Bucket system

Buckets with values (0, 1, 2, 3, 5, 8, 13, 20, 30, 50, 100) lie on the board. One reference story is placed together, all others are sorted relative to it – towards the end in parallel with a short rationale. A team gets through 50–200 items in one to two hours.

Magic estimation

The fastest method – and it happens mostly in silence: stories are distributed and assigned to a scale without discussion; afterwards everyone may silently move other people's cards. Only cards that keep moving back and forth get discussed briefly at the end. Perfect for the first pass over a whole backlog.

6 · Three-point estimation / PERT

From classic project management: instead of one value you give three – optimistic (O), most likely (M), pessimistic (P).

Suited for effort in time or money – quotes, fixed-price work, large single undertakings.

7 · #NoEstimates – not estimating at all?

The approach: slice stories as equally small as possible and simply measure throughput instead of estimating – forecasts come from historical data. This works well for settled teams with a stable flow, poorly for fixed-price quotes and new teams without history.

8 · Which method when?

9 · Tips & common pitfalls

• Keep reference stories: two or three finished stories as calibration points ("that was a 3, that an 8") get new team members up to speed in minutes.
• Outliers are gold: letting min and max explain their view is the most valuable moment of the round – never just average it away.
• Set a timebox: two estimation rounds plus discussion, then decide. At 5 vs. 8, take the 8 when in doubt.
• No anchors up front: "That's a 3 at most, right?" – and the round is ruined. Numbers only after the reveal.
• Don't convert points to hours: "1 point = 4 hours" destroys the point of relative estimation.
• An estimate ≠ a commitment: teams that get nailed to their estimates will only give you padded numbers in the future.