Story Pointing
Give the team a shared, repeatable way to size backlog items before they commit to a sprint.
01 / Summary
What Is Story Pointing?
Story pointing is the practice of assigning a relative, unit-less number, a story point, to each backlog item so the team can compare size and effort without estimating in hours. Most teams draw values from a Fibonacci-based sequence (1, 2, 3, 5, 8, 13, 21) because the widening gaps between numbers force a clear choice between neighboring sizes instead of a false sense of precision.
Because the numbers are relative rather than absolute, story pointing lets a team build a shared sense of scale from real, completed work rather than guessing at hours, and that shared scale is what makes velocity and sprint forecasting possible later.
02 / Application
When and How to Apply Story Pointing
Story pointing shows up anywhere a team needs a size before it can plan around the work: refining a backlog, planning a sprint, or calibrating how a brand-new team talks about effort in the first place.
Sprint Planning
Size the candidate stories a Product Owner has brought forward so the team commits to a sprint backlog that matches its real capacity.
Backlog Refinement
Work through upcoming stories ahead of a sprint so nothing arrives at planning still unsized.
New Team Calibration
Establish a shared point scale from scratch using a small set of agreed reference stories before a new team’s first sprint.
Cross-Team Alignment
Compare point scales across teams ahead of PI Planning so dependency and capacity conversations use the same units.
Prerequisites
Groomed Backlog
Candidate stories are written, have acceptance criteria, and are small enough to size in one sitting.
Point Scale and Reference Stories
The team has already agreed which scale to use and has two or three completed stories mapped to specific point values.
Roles and Responsibilities
Runs the session, keeps the vote moving, and calls attention to divergence without pushing the group toward a specific number.
Reveal every vote at the same time, revealing one at a time lets the first number spoken quietly anchor everyone who votes after it.
Presents each story, answers scope questions as they come up, and is the one person in the room who doesn’t vote.
Estimates as the people who will actually build the work, voting independently and discussing openly whenever votes diverge.
Rotate who explains their vote first each round, so the same senior voice doesn’t anchor every story.
Flags technical risk or unknowns during discussion so the team’s estimate reflects real complexity, not just the visible scope.
On a team without a dedicated Scrum Master, any neutral team member can facilitate, the role matters more than the title.
Scheduling and Timing
- Run story pointing as its own short session or as the tail end of backlog refinement, not squeezed into the first ten minutes of sprint planning.
- Budget roughly one to two minutes per story once the scale is established; a new team calibrating its first scale will need longer.
- Cap the session at 60-90 minutes, estimation quality drops fast once the group is fatigued.
- Revisit the point scale and reference stories every few sprints as the team’s shared understanding of size matures.
03 / Preparation
Preparing for the Session
Good story pointing depends on what happens before anyone votes: a groomed backlog, an agreed scale, and reference stories everyone can point back to.
- Groom the backlog into candidate stories that are written, scoped, and small enough to size in one sitting
- Choose the point scale the team will use (a Fibonacci-based 1-2-3-5-8-13-21 scale is the most common) and agree on it before the session, not during it
- Identify two or three reference stories with already-agreed point values the group can anchor new estimates against
-
Send scheduling communication with agenda and pre-read materials
Email Template
Subject: Story Pointing Session – [Team Name] – [Date]Hi team,
We’re holding a story pointing session on [date] at [time] to size the stories going into [sprint / upcoming work]. Please review the candidate stories linked below before we meet, so we can move through the list quickly.
Pre-read:
[Link to backlog / candidate stories]Agenda:
Confirm the point scale and reference stories, then estimate each story as a group, discussing and re-voting where votes diverge.Bring your planning poker deck (physical or the team’s digital tool) so you can vote at the same time as everyone else.
See you then,
[Facilitator Name]Calendar Invite Copy
Subject: Story Pointing Session – [Team Name]60-90 minutes. Please come having reviewed the candidate stories in [tool / link].
Agenda:
1. Confirm point scale and reference stories
2. Estimate each story (independent vote, reveal together)
3. Discuss and re-vote on outliers
4. Record final values and close - Prepare a visible voting mechanism, physical planning poker cards, sticky notes, or a shared digital voting tool everyone in the room or call can see at once
- Download and prepare the Estimation Reference Sheet and the Facilitator’s Presentation
04 / Facilitation
Facilitating the Session
The facilitator’s job is to keep votes independent, keep discussion focused on the story in front of the group, and keep the session moving.
Setting the Scale
Open by confirming the point scale and walking through the reference stories so every vote that follows shares the same anchor.
Running the Vote
Read each story aloud, give the team a moment to think, and have everyone reveal their card or vote at the same time.
Resolving Divergence
When votes spread wide, ask the highest and lowest voters to explain their reasoning before re-voting, not to justify a compromise number.
Presenting the Story Pointing Process
-
Introduction
- What is story pointing and why relative sizing beats hours
- Today’s goal: size [N] stories before we close
-
Establish the Point Scale
- Confirm the Fibonacci-based scale (1, 2, 3, 5, 8, 13, 21)
- Walk through the team’s agreed reference stories
-
Round One: Independent Estimates
- Present the first story and answer scope questions
- Every team member votes privately, then reveals at the same time
-
Discuss Outliers and Re-Vote
- High and low voters explain their reasoning first
- Re-vote once, then take the majority or nearest-agreed value
-
Repeat Across the Backlog
- Move through the remaining stories at a steady pace
- Flag any story that can’t converge after two rounds for offline discovery
-
Record and Close
- Log every point value in the backlog tool before the room breaks up
- Note which stories were flagged and need more discovery
Common Anti-Patterns to Avoid
- Converting story points directly into hours undoes the purpose of relative sizing and breaks down the first time team composition changes.
- Revealing votes one at a time instead of simultaneously lets the first number spoken quietly anchor everyone who votes after it.
- Re-estimating a story mid-sprint because it turned out harder than expected corrupts the velocity history the team relies on for future forecasts.
- Letting the most senior or loudest voice explain their vote first every round quietly turns the team’s estimate into that one person’s estimate.
05 / Follow-Up
After the Session
Expected Outputs
Share the finalized point values with the team and any dependent teams right away, while the reasoning behind each estimate is still fresh, and route flagged stories back into discovery before they resurface at a future session.
Follow-Up Communication Template
Hi team,
Thanks for a focused story pointing session today. Here’s where things landed.
Final Point Values
[Story] – [Points]
[Story] – [Points]
[Story] – [Points]
Flagged for Follow-Up
[Story] – needs more discovery before it can be sized with confidence
Next steps: the pointed backlog is updated in [tool], and flagged stories will come back for re-estimation once the open questions are resolved.
Thanks,
[Facilitator Name]
Ongoing Next Steps
- Log the session’s point values against completed work each sprint to build a real velocity trend, not a guess.
- Follow up on any flagged story with the discovery work it needs before it returns to a future pointing session.
- Revisit the reference stories every few sprints; a scale that made sense at team formation drifts as the team’s skills and codebase mature.
- Share the pointed backlog with dependent teams before PI Planning so cross-team capacity conversations start from the same numbers.
- Retire completed reference stories that no longer represent typical work and replace them with recent examples.
- Watch for a team’s average votes-per-story creeping up over time, a sign the group is drifting toward inflating points rather than resolving genuine complexity.
06 / References and Resources
References and Resources
- Mountain Goat Software: Planning Poker and Agile Estimating with Story Points
- Atlassian: What Are Story Points in Agile and How Do You Estimate Them?
Complimentary Workshops
Epics and Capabilities Workshop
Turn portfolio goals into sized, fundable Epics and Capabilities before a single Feature hits the backlog.
Ready to point the backlog?
Download templates and tools to run your own Story Pointing session.