Relative sizing is an agile estimation technique where you size work by comparing it to other work ("this is about twice as big as the login story") instead of predicting hours. Planning poker is the most common way to do it: each person privately picks a card from a non-linear scale, everyone reveals at once, and the team discusses the gaps until it converges on a number.
This guide covers both halves: why relative sizing works, how to pick reference stories, and exactly how to run a planning poker round, including a facilitator script and a worked example where the votes come back 3, 5, 5, 13.
What is relative sizing?
In relative sizing you never ask "how long will this take?" You ask "how big is this compared to something we already understand?" The answer is expressed in an abstract unit, usually story points, whose only meaning is the ratio between items. A 6-point story should be roughly twice a 3-point story. Neither number says anything about days.
Teams use relative estimation in agile for three practical reasons:
- People compare better than they predict. Most of us cannot say whether a feature takes 14 or 22 hours, but we can usually say it is bigger than feature A and smaller than feature B. Relative judgments are faster and more consistent across a group.
- Skill differences stop mattering. A senior developer might finish a story in a day that takes a newer teammate three. They will still usually agree it is "about the size of the CSV export story." The size is shared even when the speed is not.
- Time falls out of the data instead of going in. Once you know your team completes around 30 points a sprint (its velocity), you forecast dates from history. You never have to defend a guess about Tuesday afternoon. See how to calculate team velocity for the mechanics.
Story points bundle together how complex the work is, how much of it there is, and how much is unknown. If your team keeps arguing past each other on those dimensions, read complexity vs effort in story points. If someone asks how many hours a point is, send them to story points vs hours.
Relative sizing vs absolute estimation
| Absolute (hours/days) | Relative (points/sizes) | |
|---|---|---|
| Question asked | "How long will this take?" | "How big is this compared to X?" |
| Depends on who does it | Yes | Mostly no |
| Precision implied | High (often false) | Deliberately coarse |
| Converts to dates via | The estimate itself | Historical velocity |
| Typical failure | Padding, pressure to shave hours | Reference drift, points treated as hours |
Relative sizing is not more "accurate" in the sense of predicting a single story. It is more consistent, and consistency is what makes sprint-level and release-level forecasting work.
Choosing reference stories
Relative sizing only works if everyone is comparing against the same thing. Before your first session, pick two or three reference stories from recently completed work.
What makes a good reference story:
- Everyone remembers it. Completed in the last few sprints, ideally touched by most of the team.
- It went roughly as expected. Avoid the story that blew up because of a surprise outage. You want a typical example.
- It spans the middle of your scale. Pick one small (2), one medium (5), and one large (8 or 13). Anchoring only on a 1 makes everything look huge.
- It is your kind of work. A front-end-heavy team needs a front-end reference; a data team needs a pipeline reference.
Write them down where people can see them during estimation. A simple table in your team wiki is enough:
| Points | Reference story | Why it's this size |
|---|---|---|
| 2 | Add "last login" column to admin user table | One screen, existing data, no unknowns |
| 5 | CSV export of filtered orders | New endpoint, file generation, some edge cases with large result sets |
| 8 | Password reset via email | Token handling, email template, security review, expiry rules |
| 13 | Migrate notifications to new queue service | Two services, data migration, rollback plan, partial unknowns |
If you are starting a brand-new team with no history, use affinity sizing (below) to sort 15 to 20 backlog items into piles first, then call the middle pile a 5. Revisit them every quarter so they stay stable.
How planning poker works, step by step
Planning poker (also called estimation poker or Scrum poker) was popularized by Mike Cohn and is based on Wideband Delphi, a 1970s technique where experts estimate independently, discuss, and estimate again. The poker estimation technique keeps the core idea: independent votes first, conversation second.
- Present the story. The Product Owner reads the story and acceptance criteria. Two minutes, not twenty.
- Clarify. The team asks questions about scope and intent. Implementation design is out of bounds at this stage.
- Vote privately. Each estimator picks a card. Nobody announces a number. This is the step that protects you from anchoring, the bias Kahneman and Tversky described where the first number heard pulls everyone's judgment toward it.
- Reveal together. All cards turn over at once.
- Discuss the spread. If votes are close, take the consensus and move on. If they are far apart, the highest and lowest voters explain their reasoning first.
- Revote. Everyone votes again with the new information. Most stories converge within one or two revotes.
- Record and move on. Write the number, plus any assumption that changed the estimate ("assumes we reuse the existing email service").
Choosing a planning poker scale
The cards use a non-linear scale because uncertainty grows with size. The gaps force you to pick "closer to 8 or closer to 13" rather than debating 9 vs 10.
| Scale | Values | Good for |
|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21, 34... | Most software teams |
| Modified Fibonacci | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 | Teams with tiny tasks and epic-level items in one backlog |
| T-shirt | XS, S, M, L, XL, XXL | Roadmap sizing, mixed or non-technical groups |
Most decks also include a ? card ("I don't understand this well enough to vote"). Treat it as a signal that the story needs clarification, not a vote to be averaged. The full comparison, including powers of 2 and a copy-paste scale reference card, is in Fibonacci vs T-shirt sizing.
Facilitator script
Exact wording matters more than people expect. Neutral phrasing keeps the room from drifting toward whoever talks first. Here is a script you can read almost verbatim.
Opening the session
"We have six stories today and about 45 minutes. Our references are on screen: the admin column is a 2, CSV export is a 5, password reset is an 8. If you can't vote, use the question mark. That's useful information, not a failure."
Presenting a story
"Next is ORD-412. [PO reads it.] Questions about what it should do? Let's hold the 'how' for after we vote."
Before the vote
"Compare it against the references, not against a clock. Vote when you're ready. Please don't say a number out loud."
After the reveal, when votes are close (adjacent values)
"We've got 5s and 8s. Anyone strongly against 8? ... Okay, 8, moving on."
After the reveal, when votes are spread
"We have a 3 and a 13. [Lowest voter], what were you picturing? ... [Highest voter], what did you see that made it a 13?"
Always ask the low voter first. Senior people often vote high because they've seen the hidden problems, and if they speak first, the low voter may never mention the shortcut they know about.
Calling the revote
"With what we just heard, let's vote again. Same rules."
When it won't converge after two revotes
"We're still split between 5 and 13, which tells me we don't share the same picture of this story. Options: take the higher number, split it, or park it with a spike. Which do we want?"
Closing the story
"8 it is. I'm noting the assumption that we reuse the existing export service. Next story."
The same script works remotely; the facilitator just has to call on people by name more often.
Worked example: votes 3, 5, 5, 13
Here is a realistic round. The team's references are the ones from the table above.
Story: "As a customer, I can download my invoices as a PDF from the billing page."
Round 1 votes:
| Person | Role | Vote |
|---|---|---|
| Priya | Front-end dev | 3 |
| Marcus | Back-end dev | 5 |
| Jen | Back-end dev | 5 |
| Tomás | QA | 13 |
Facilitator: "Priya, you voted 3. What did you have in mind?"
Priya: "We already render invoices as HTML. I assumed we pass that to a PDF library and add a download button. One screen, smaller than CSV export."
Facilitator: "Tomás, 13. What did you see?"
Tomás: "Invoices for EU customers need VAT breakdowns and our HTML template doesn't handle multi-currency layouts. Last time we touched invoices, legal reviewed every format change. Also, some accounts have 400+ invoices. Is this one-at-a-time or bulk?"
Facilitator (to the PO): "Is bulk download in scope?"
PO: "No, one invoice at a time. Bulk is a separate story. But yes, EU invoices need to be correct."
Marcus: "If legal review is required, that's a real cost. Template changes for VAT are maybe half a day by themselves."
Round 2 votes: Priya 5, Marcus 8, Jen 8, Tomás 8.
Facilitator: "Priya, anything that keeps you at 5?"
Priya: "No, I didn't know about the VAT layout. 8 is fine."
Result: 8 points. Recorded assumptions: single-invoice download only; includes VAT layout fix; legal review required. A new story, "Bulk invoice download," goes to the backlog unestimated.
Notice what happened. The 13 wasn't wrong and the 3 wasn't wrong. They were estimating different stories. The discussion surfaced two hidden facts (VAT layout, legal review) and removed one piece of imagined scope (bulk download). That is the actual value of the round. The number is a by-product.
Relative sizing without poker: affinity estimation
When you have 40 unestimated backlog items, card-by-card poker is too slow. Use affinity sizing first:
- Put your reference stories on a board at their point values.
- Team members silently place items to the left (smaller) or right (bigger) of the references. Anyone can move any card.
- Cards that keep getting moved are discussed briefly.
- Draw column boundaries and assign each column a point value.
A team can sort a large backlog in under an hour this way, then use planning poker only for the items closest to the next sprint. T-shirt sizing works well for this kind of rough pass too.
Common mistakes and how to fix them
| Mistake | What it looks like | Fix |
|---|---|---|
| Points become hours | "An 8 is a day, right?" | Stop converting. Compare to references, forecast with velocity. |
| No shared reference | Same story gets a 3 one sprint and an 8 the next | Pin 3 reference stories on screen every session. |
| Averaging spread votes | 3 and 13 averaged to "about 8" | Spread means different understandings. Discuss before revoting. |
| Senior person speaks first | Everyone revotes to match the lead | Simultaneous reveal; ask the lowest voter first. |
| Debating 5 vs 8 for ten minutes | Endless rounds on adjacent values | Adjacent values are close enough. Take the higher and move on. |
| Estimating unready stories | Lots of "?" cards | Push it back to refinement. Use a readiness checklist. |
| Huge numbers accepted | A 40 goes into the sprint | Anything above 13 gets split before planning. See estimating large epics. |
Running planning poker remotely
Remote teams can't hold up physical cards, so the tool has to enforce the hidden vote and the simultaneous reveal. Beyond that, the same practices apply: send stories ahead of time, keep cameras on if your team is comfortable with it, and have the facilitator call on people by name during discussion so the loudest connection doesn't dominate.
Alignlee's free planning poker handles the mechanics: votes stay hidden until reveal, you can pick a Fibonacci, Modified Fibonacci, or T-shirt deck, and each vote carries a confidence slider so a hesitant 13 counts for less than a confident 8. No signup is needed, which makes it easy to pull in a stakeholder for one story.
FAQ
What is relative sizing in agile?
Relative sizing is estimating work by comparing items to each other instead of predicting time. A team picks a few reference stories with agreed sizes and asks whether new work is smaller, similar, or larger. The result is a unit like story points that is consistent across the team and turns into dates through velocity.
What is the relative sizing estimation technique in agile?
The most common relative sizing technique is planning poker: private votes on a Fibonacci-style scale, simultaneous reveal, discussion of the highest and lowest votes, then a revote. Affinity estimation (sorting cards on a wall relative to references) and T-shirt sizing are also relative techniques, usually used for rough sizing of many items at once.
How does the planning poker estimation technique work?
The Product Owner presents a story, the team clarifies scope, and everyone privately selects a card. All cards are revealed at once. If votes differ widely, the outliers explain their thinking and the team votes again until estimates converge, usually within two or three rounds.
What scale is used in planning poker?
Most teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) or Modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). T-shirt sizes (XS to XXL) are common for rough roadmap sizing. The widening gaps reflect that bigger work carries more uncertainty.
Is poker sizing in agile the same as story points?
Planning poker is the process; story points are the most common unit it produces. You can run planning poker with T-shirt sizes or any other relative scale, and you can assign story points without poker. Poker is popular because the private vote and simultaneous reveal reduce anchoring and get everyone's knowledge on the table.