Backlog refinement makes upcoming work easier to understand and choose. Estimation can be part of it, alongside clarifying outcomes, adding detail, splitting large items and reconsidering order.
Planning poker is useful when independent estimates can reveal different interpretations. It does not need to be the first activity, and it does not need to be used for every item.
Refinement and sprint planning answer different questions
Refinement asks whether upcoming items are clear enough for useful decisions. Sprint planning establishes a goal, selects work and creates a plan for the sprint. Arriving at planning with every important question still unanswered makes those decisions harder.
The Scrum Guide describes refinement as an ongoing activity, rather than a separate mandatory event with one prescribed meeting format. The agenda below is a practical example you can adapt, not a rule of Scrum.
Prepare a short list of useful items
Do not spend the whole session reading dozens of distant ideas. Select a manageable slice of near-term work. If a detail is not needed for the next decision, it may be reasonable to leave it open.
- Write the user or stakeholder outcome in plain language.
- Include acceptance examples, not only a broad feature title.
- Identify the product question or ordering decision that needs an estimate.
- Link relevant designs or technical context in your own backlog.
- Bring someone who can clarify the outcome or arrange a follow-up.
An example 45-minute refinement agenda
Adjust the balance to the work. A new integration may need more discovery and fewer votes; a familiar set of changes may be estimated quickly. The value is in leaving with better decisions, not in reaching a predetermined number of completed rounds.
| Time | Activity | Useful output |
|---|---|---|
| First 5 minutes | Confirm the purpose and select items | A shared focus |
| Next 10 minutes | Clarify the first items and split obvious large work | Understandable outcomes |
| Next 20 minutes | Run short planning poker rounds where perspectives differ | Estimates and explicit assumptions |
| Final 10 minutes | Capture questions, ownership and ordering implications | Decisions and follow-up |
Check the story before asking for cards
Ask the team to explain what a user will be able to do after the item is complete. Then ask what verification belongs to the item, what depends on another person or service, and what has changed since the last comparable piece of work.
If those answers differ significantly, clarify them first. A long title or a point value does not make a story ready. Keep the estimate attached to the understanding that produced it, so a later scope change is visible.
Handle uncertainty explicitly
A ? card is useful feedback. It can mean that a story needs a missing acceptance example, a small investigation or a conversation with an external team. Write down the question and choose an owner or next step instead of forcing a number.
For example, a data-import story might depend on a provider's rate limits. Investigate those limits before treating the integration estimate as settled. If the item can be divided into a small verified import and a later bulk-processing feature, discuss that split too.
Keep durable records outside the temporary room
Use the PointRoom ledger to review accepted estimates during the session. Before the room ends or expires, copy decisions into your backlog. Include the assumptions and outstanding questions; a number without its scope is easy to misinterpret.
At the next session, check whether the answers changed the work. Re-estimate when that helps a decision, rather than preserving a stale number merely because it is already in the tracker.
Sources and further reading
For the underlying methods and framework, start with these primary sources. Worked examples and suggested agendas above are illustrative.
A shared estimate starts with a shared table.
Create a free room, invite your team and try one clear story. No signup needed.
Create a free planning poker room