Agile estimation techniques compared: eight ways to size work and when to use each

There is no single best agile estimation technique, only the best fit for the decision in front of you. Planning poker is the strongest all-rounder for sizing well-understood stories in story points with the whole team. Affinity estimation and the bucket system size large backlogs quickly. T-shirt sizing suits roadmaps. Three-point estimates and Wideband Delphi produce ranges for risky or expensive work, and #NoEstimates replaces estimating with slicing work small and counting it.

Many teams combine two or three of these: rough sizes for the roadmap, a fast group method for a big backlog and planning poker for the next sprint or two. The table below compares all eight at a glance, and the sections after it explain how each one works, where it shines and where it lets you down.

Agile estimation techniques at a glance

Speed and precision here are relative, and they are judgements rather than measurements. A low-precision technique is not worse; it is honest about how much is known. A roadmap item sized as L is no less useful than a story sized as 5. It simply answers a different question.

Planning poker

In planning poker, the product owner presents a story, the team asks questions, and then everyone picks a card in secret from a deck such as 1, 2, 3, 5, 8 and 13. All the cards are revealed at once. If the votes agree, the number is recorded; if not, the people with the highest and lowest cards explain their thinking and the team votes again.

James Grenning described the technique in 2002 to stop release planning getting bogged down and to involve the whole team rather than just its most vocal members. Mike Cohn’s 2005 book Agile Estimating and Planning then popularised it among Scrum teams. The simultaneous reveal is the clever part: nobody can anchor on someone else’s number, so quieter people’s views surface.

• Strengths: involves everyone, reduces anchoring, surfaces hidden assumptions and builds shared understanding.
• Weaknesses: too slow for a backlog of a hundred items, and only as good as the refinement that comes before it.
• Use it for: stories heading into the next sprint or two.

Our complete guide to planning poker and step-by-step session guide go deeper.

T-shirt sizing

T-shirt sizing swaps numbers for XS, S, M, L and XL. Because nobody mistakes a size for a number of hours, it keeps conversations on comparison, and non-developers can join in easily. That makes it a favourite for roadmap planning and for a first pass over a new backlog.

The catch is that sizes don’t add up: as Mike Cohn points out, you can’t tell your boss you’ll be done in three mediums and four larges. Teams that need forecasts either map sizes to numbers or move to story points.

• Strengths: very quick, easy for anyone to understand, and good at keeping early conversations rough.
• Weaknesses: sizes mean different things to different people unless anchored, and they can’t be summed.
• Use it for: roadmaps, epics and early product discovery.

Our T-shirt sizing guide covers sessions, mappings to numbers and when to switch.

Affinity estimation and the bucket system

Both techniques trade some discussion for a lot of speed, which is exactly what you want when a backlog has 80 items and you have one afternoon.

Affinity estimation

In the version Mountain Goat Software describes, the team puts the values of its scale across the top of a wall or online board. Estimators then place items under the value they think fits, in silence. Anyone who disagrees can move an item, but each item can only be placed once and moved once. Anything that someone wants to move a second time goes onto a discussion pile, which the team estimates with planning poker afterwards.

A popular variation skips the numbers at first: the team silently sorts items from smallest to largest, then draws lines between groups and assigns values. Either way, the silence is deliberate. It stops one person’s view dominating and keeps the pace high. Our guide to affinity estimation and the bucket system has a full walkthrough.

• Strengths: sizes dozens of items in one sitting, keeps everyone involved and shows at a glance where the team disagrees.
• Weaknesses: less discussion per item, so hidden assumptions can slip through on items nobody moved.
• Use it for: a new or inherited backlog, or a periodic re-size of everything beyond the next few sprints.

The bucket system

The bucket system works well with larger groups. Lay out “buckets” labelled with values from your scale, for example 1, 2, 3, 5, 8, 13, 20, 40 and 100. The group places one item together in a middle bucket as an anchor, then a few more by quick discussion. The remaining items are divided among the participants, who each place their share silently. Finally everyone reviews the buckets, and any item someone questions is discussed and moved.

Because the work is shared out, the bucket system can get through a large backlog in a single session, even with more people than planning poker suits. The trade-off is that most items are placed by one person, so treat the result as a first pass and refine the items that matter most.

• Strengths: scales to bigger groups and large backlogs, and the review step catches the worst misplacements.
• Weaknesses: many sizes reflect one person’s view, so results depend on who happened to place each item.
• Use it for: big backlogs, programme-level sizing with several teams in the room, or a first pass before planning poker.

Dot voting

Dot voting gives each person a fixed number of dots to place on the options they favour. The Nielsen Norman Group suggests giving each person about a quarter as many dots as there are options. The result is an instant heat map of what the group cares about.

Strictly, dot voting ranks rather than sizes, so it is better at choosing than at estimating. In estimation sessions it is useful for deciding which items to discuss first (“put your dots on the stories you think are riskiest”) or for breaking a deadlock between two or three candidate sizes. Watch for its known biases, such as people campaigning for an option and people following where others have already voted. Private or digital votes, revealed all at once, reduce both.

• Strengths: almost no setup, works with any group and makes priorities visible immediately.
• Weaknesses: produces a ranking rather than a size, and is easily swayed when people can see votes as they are cast.
• Use it for: choosing what to estimate first, narrowing options and breaking deadlocks.

Three-point estimates (PERT)

A three-point estimate asks for three numbers instead of one: optimistic (O), most likely (M) and pessimistic (P). The best-known way to combine them comes from PERT, which the US Navy’s Special Projects Office developed from 1957 with the consultancy Booz Allen Hamilton for the Polaris missile programme:

• Expected value = (O + 4M + P) / 6
• Standard deviation = (P - O) / 6, a rough measure of the spread

Say a team is asked how long it will take to move the customer database to a new cloud region. The optimistic case is 3 days, the most likely 5 and the pessimistic 14, because nobody has tested the replication tooling at full volume. The expected value is (3 + 20 + 14) / 6, about 6.2 days, with a standard deviation of about 1.8 days. The long pessimistic tail pulls the expected value above the most likely case, which is exactly the conversation stakeholders need to have.

Use three-point estimates selectively: for risky items, fixed-date commitments and release ranges. Remember that the PERT formulas are a simplification. They assume a particular shape of distribution, and when several streams of work must all finish before a milestone, a calculation that follows a single path tends to be optimistic.

• Strengths: makes uncertainty explicit and gives stakeholders a range instead of a single hopeful number.
• Weaknesses: slower, and only as good as the optimistic and pessimistic guesses, which are hard to make well.
• Use it for: risky items, deadline conversations and anything with a fixed date attached.

Wideband Delphi

Wideband Delphi is the heavyweight of the group and a forerunner of planning poker. The original Delphi method was developed at the RAND Corporation in the 1950s and 1960s: experts estimated anonymously and converged through rounds. In the 1970s Barry Boehm and John A. Farquhar adapted it into Wideband Delphi, adding more discussion between rounds, and Boehm described it in his 1981 book Software Engineering Economics.

In “Stop Promising Miracles” (Software Development magazine, February 2000), Karl Wiegers describes a practical version with a moderator, the project manager and two to four other estimators:

1. Plan and kick off. Define the problem, choose the estimators and agree the units, in a kickoff meeting of up to an hour.
2. Prepare individually. Each estimator lists the tasks they think are needed, estimates each one and notes their assumptions.
3. Estimate in rounds. The moderator charts everyone’s totals without names. The group discusses tasks and assumptions, then everyone revises silently. Repeat until the estimates converge, four rounds pass or the meeting time, typically two hours, runs out.
4. Assemble and review. Merge the task lists and estimates, then review the result as a range rather than a single number.

It is slow and needs experienced people, but it produces something the lighter techniques don’t.

• Strengths: a detailed task list, written assumptions and a range that reflects real disagreement, with anonymity limiting the pull of loud or senior voices.
• Weaknesses: takes hours, and needs several experienced people at the same time.
• Use it for: large, high-stakes estimates such as a bid, a platform migration or a new product, not sprint stories.

#NoEstimates

#NoEstimates is less a technique than a challenge to the whole activity. Vasco Duarte credits Woody Zuill with the earliest recorded tweet using the hashtag, and Duarte’s book NoEstimates: How to Measure Project Progress Without Estimating sets out a practical approach. The question it asks is a fair one: what decision will this estimate inform, and is there a cheaper way to inform it?

In practice, teams following #NoEstimates ideas slice work into small items of similar size, count how many they finish each week or sprint, and forecast by projecting that delivery rate forward. If a team finishes 8 to 12 items a sprint and 40 remain, the answer is roughly four to five sprints, with no estimation meeting at all. It works best with a stable team, disciplined story splitting and stakeholders who accept forecasts as ranges.

• Strengths: no estimation meetings, forecasts based on what actually happened, and constant pressure to keep work small.
• Weaknesses: needs consistent slicing and some history before forecasts mean anything, and some stakeholders will still expect estimates.
• Use it for: teams with a steady flow of small items, or as a second opinion alongside velocity.

Even teams that keep estimating can borrow its best habit: slicing work small enough that size stops being the main source of uncertainty.

How to combine estimation techniques

The techniques work best as layers, each matched to how much you know and what you need to decide. A common combination looks like this:

Two rules keep a combination coherent. First, use one scale per level: sizes for the roadmap and points for sprint-ready stories, and never mix them in the same velocity. Second, let forecasts come from history, whether that is velocity in points or throughput in items, rather than from adding up estimates made with different techniques.

Four questions to ask before you choose

• What decision will the estimate inform? Ordering a roadmap, filling a sprint and pricing a bid need very different levels of detail.
• How much do we know? The less you know, the coarser the technique should be. Precision on a vague item is false comfort.
• How many items are there? Ten items suit planning poker; a hundred call for affinity estimation or the bucket system first.
• Who needs to take part? Stakeholders can join T-shirt sizing and dot voting easily; sprint estimates belong to the people doing the work.

A worked example

A team takes over a mobile banking app with a backlog of 120 items and a roadmap review in six weeks. In the first week they run an affinity session and size the whole backlog in an afternoon, setting aside 15 items they couldn’t agree on. For the review, the product owner sizes the six roadmap themes in T-shirt sizes with the stakeholders.

From then on, each refinement session takes the top of the backlog through planning poker, starting with the disputed items as they rise. One item, a change to how customers confirm payments, has a hard deadline, so it gets a two-day spike and then a three-point estimate. The deadline conversation starts with a range rather than a guess, and nobody spent a week estimating items that may never be built.

Estimating with a distributed team

Distributed teams can run almost all of these online. The independent-first habit that Delphi and planning poker share also works well asynchronously, with people in different time zones voting on their own time and the team meeting only to discuss disagreements. Our guide to async planning poker shows how.

On planningpoker.org With a free Laya account, Async Poker lets everyone vote on their own time before a due date, with optional comments. A moderator then finishes voting and the team reviews the results together.