Story point estimation compares the effort needed to complete one backlog item with other work the team understands. For a useful planning-poker session, agree on a scale, choose reference stories, reveal estimates together, discuss the reasons for a wide spread, and estimate again after clarifying the scope.
An agile whiteboard for sprint planning can keep the stories, reference items, and questions visible during that discussion. This worked example follows a checkout team through three items, including one that remains unestimated because a dependency is unresolved.
Prepare a comparable set of stories
Story points express relative effort, including the amount of work, complexity, and uncertainty. Mountain Goat Software's explanation of story points also includes the work needed to reach the team's Definition of Done. Development is not the whole estimate if testing, integration, or documentation is required to finish the item.
Before the session, give each story a user outcome and enough acceptance detail to discuss it. Remove duplicates, separate unrelated outcomes, and identify dependencies that could change the work. An estimate of “show the order summary” means little until the team knows which fields, states, and data sources it includes.
For our example, the team brings these three items:
- Rename a customer's saved address from “Address 1” to a label they choose.
- Validate a postal address using an external provider and explain problems to the customer.
- Show order-confirmation details after checkout using fields already returned by the order service.
The people who will do the work estimate it. The Product Owner explains intended behavior and scope. A facilitator manages the conversation and records questions. In Scrum, the Developers are responsible for sizing backlog items; the framework does not require a particular point scale or planning-poker technique.
Choose reference items and one scale
This team uses 1, 2, 3, 5, 8, and 13. Choose a scale before voting and use its values consistently. Other scales are possible, but switching between them during the same session makes the comparison harder to follow.
The team's two reference stories are completed work: a two-point saved-address label edit and an eight-point delivery-option change that needed new service behavior and several error states. Keep the scope and completion conditions beside the numbers. A reference is useful because people remember the work, not because “two” has a meaning on its own.
Ask whether a new story is nearer the small edit or the larger integration, and why. Do not define a point as a fixed number of hours. An eight-point item can require more overall effort than a two-point item without taking four times as long on the calendar; availability, parallel work, and dependencies affect elapsed time.
Run a quiet first vote
Read one item and let the Product Owner answer scope questions before anyone proposes a number. Each estimator then picks a value privately. Reveal together, ask the lowest and highest estimators what work they included, and give others a chance to add missing assumptions. This is the core process described in Mountain Goat Software's Planning Poker guide.
Suppose four estimators consider the saved-address label item. They reveal 2, 2, 3, and 3. The lower estimates assume only the displayed label changes. The higher estimates include changes to address validation. The Product Owner confirms that validation and delivery behavior remain the same. The team checks its two-point reference, votes again, and agrees on 2.
No estimate was lowered because a deadline required it. The change came from removing work that was never part of this item. Record “label only; validation unchanged” beside the estimate so someone absent from the meeting can understand the boundary.
Resolve disagreement before recording a number
The address-validation item produces 5, 5, 8, and 13. The lowest estimate assumes an existing service handles provider responses. The highest includes timeout handling, an unavailable-provider state, and a new choice about whether customers can continue with an unverified address.
The team has uncovered a product decision and a technical unknown. It does not record the average or select 8 simply because it sits between the extremes. First, the Product Owner must decide the fallback behavior; an engineer must inspect the current integration. The item returns to refinement with those two questions and their owners. A separate investigation can be planned if the team needs it, with a clear question to answer rather than a promise to deliver the whole feature.
For the order-confirmation item, the first round is 3, 3, 5, and 5. The higher estimates include a downloadable receipt, which the story does not request. The Product Owner clarifies that the item displays the existing order number, items, total, and delivery choice; downloading a receipt is separate work. After considering the empty and loading states, the team votes again and agrees on 3.
| Checkout item | First round | Clarification | Recorded result |
|---|---|---|---|
| Change saved address label | 2, 2, 3, 3 | No address-validation change | 2 points |
| Validate address with a provider | 5, 5, 8, 13 | Fallback behavior and existing service support are unknown | Unestimated; return to refinement |
| Show order-confirmation details | 3, 3, 5, 5 | Existing fields only; no receipt download | 3 points |
The agreed values come from a new discussion and vote. They are not averages of the first round. In particular, this team's scale contains no 4, so a 3-versus-5 disagreement does not automatically become four points. If estimates remain far apart, record what is still unclear instead of inventing precision.
Record the estimate and the remaining questions
For each estimated item, save the agreed value, the scope decision that affected it, and the reference story used for comparison. For an unestimated item, save the question and who will answer it. The validation story should not appear as zero points or disappear from the board; either would hide the outstanding work.
The two agreed estimates in this example total five points, but that total is not a sprint commitment. In Sprint Planning, the team still considers the Sprint Goal, available capacity, dependencies, and its own past performance. Do not add another team's points or compare developers by how many points they finish. The scale belongs to the team's shared understanding of its work.
If the scope later changes from “display existing fields” to “generate and download a receipt,” revisit the item and its estimate. Preserve the earlier scope note so the change is visible. Re-estimation is useful when the work changes; quietly editing a number to make a past plan look accurate removes the information the team needs to learn.
Keep the estimation discussion in Boardmix
Create areas for reference stories, the current story, revealed estimates, agreed scope, and unresolved questions. Place the two reference items where everyone can see them. For the current item, show the user outcome and acceptance conditions before collecting a vote.
Use physical cards or a tool that supports a private vote and simultaneous reveal, then record the revealed values on the board. Writing numbers on a shared visible canvas before everyone chooses can influence later voters. Boardmix serves as the common place for the story and discussion record in this setup; the private vote is a separate part of the process.
Open a Boardmix board to organize the reference items and the three checkout stories. Keep “2—label only,” “unestimated—clarify provider fallback,” and “3—existing confirmation fields” beside their respective items rather than leaving only a row of numbers.
