Scrum Poker Example Session: 5 Stories, Start to Finish
The fastest way to understand Scrum Poker is to watch a real session unfold - not five isolated rules, but one team working through a real backlog, disagreements and all. This page walks through a full session: four developers, five stories, one facilitator, ending with the exported round history. For the theory behind any of this, see the complete Scrum Poker guide or the rules reference.
The team: Priya (facilitator), Sam, Jordan, and Alex - four developers estimating a sprint's worth of refined backlog items on the standard Fibonacci deck.
Story 1: Add a "resend confirmation email" button
Priya reads the story and its acceptance criteria aloud. Everyone votes privately.
Round 1: Sam 2, Jordan 3, Alex 2, Priya 3.
A tight spread - the team notes 3 (rounding to the higher of the two clustered values, a common house convention) and moves on without discussion. No outlier means nothing to talk about.
Story 2: Let users export their order history as a CSV
Round 1: Sam 3, Jordan 3, Alex 8, Priya 3.
Alex is the outlier. Priya asks Alex to explain first: "Our order table doesn't paginate past 500 rows in the export query right now - some enterprise customers have 10,000+ orders, so this needs a streaming export, not the simple query the other stories like this used." Sam hadn't considered accounts that large; Jordan points out the pagination fix is probably a shared utility they'll want elsewhere too.
Discussion, 90 seconds. The team agrees the streaming concern is real and scopes it into the story rather than treating it as a separate one.
Round 2: Sam 5, Jordan 5, Alex 8, Priya 5.
Tighter, but Alex still sees more risk than the others. Priya calls it at 5 with a note to keep an eye on query performance during implementation - a healthy resolution, not a forced average.
Story 3: Integrate a new payment provider's checkout flow
Round 1: Sam 5, Jordan 13, Alex 8, Priya 5.
A real spread. Jordan explains: "I looked at their docs yesterday - the sandbox environment doesn't support testing declined-card flows at all, so we'd be shipping that error path without ever testing it against their sandbox." That's a genuine unknown, not just caution.
Discussion, three minutes. The team decides a short spike to confirm the sandbox limitation and find a workaround (or accept the testing gap with a monitoring plan) makes more sense than estimating around an open question.
Result: parked for a spike, not re-voted. Forcing a number here would have been theater - the honest move is investigating first. See estimating spikes and research tasks for how this fits into a sprint.
Story 4: Fix a rounding error in cart total calculations
Round 1: Sam 2, Jordan 2, Alex 3, Priya 2.
Near-unanimous. The cause is already diagnosed (a floating-point issue at a specific calculation step), so this estimates like a small, well-understood fix. 2, no discussion needed.
Story 5: Add role-based permissions to the admin dashboard
Round 1: Sam 13, Jordan 8, Alex 21, Priya 13.
Every vote is high, and the spread itself is a signal. Priya asks Alex (the highest) first: "This touches three roles, five screens, and both the API layer and the UI - I don't think this is one story." Jordan agrees but had mentally scoped it smaller, to just the API changes.
Discussion, two minutes. Rather than re-voting, the team agrees the story should be split - by role, starting with admin-only permissions, then editor, then viewer. See splitting user stories for estimation for the pattern.
Result: split before estimating, not forced into a number. A universally high vote is often a splitting signal, not a "let's just call it a 13 and move on" signal.
The exported round history
At the end of the session, Priya exports the round history as a CSV - the same export a real OneMorePoint room produces, useful for retro discussion and future calibration:
| Round | Story | Sam | Jordan | Alex | Priya | Average |
|---|---|---|---|---|---|---|
| 1 | Add a "resend confirmation email" button | 2 | 3 | 2 | 3 | 2.5 |
| 2 | Let users export their order history as a CSV | 5 | 5 | 8 | 5 | 5.75 |
| 3 | Fix a rounding error in cart total calculations | 2 | 2 | 3 | 2 | 2.25 |
Story 2's payment integration was parked for a spike and story 5 was split before a final estimate landed, so neither appears in the exported average until they're re-estimated as smaller, ready stories - exactly what the history is for: a written record of what actually got sized, not a fudged number for what didn't.
What this session actually demonstrates
Two of five stories - a real 40% - didn't get a clean first-round number, and neither was resolved by averaging or by the facilitator picking a compromise. One got split, one got parked for a spike. That's not a failed session; it's the technique working as intended. The value of Scrum Poker isn't the numbers it produces on easy stories (any method would get story 1 and story 4 right) - it's what happens on stories 2, 3, and 5, where the vote surfaces a disagreement that a single estimator, or a silent average, would have missed entirely.
Run this with your own backlog
Create a free room, pull five real stories from your own backlog, and see which ones turn out to have hidden disagreement. No sign-up, every deck type included, and the round history exports the same way shown above.