How to Run an Effective Backlog Refinement Session

The aim is to make upcoming work:

• Clear enough for the team to discuss.
• Understood from product, design, development and testing perspectives.
• Small enough to complete within a Sprint.
• Sized where this helps the team plan.
• Ordered according to value, risk and dependencies.

1. Prepare Before the Session

Purpose: Give the team enough context to have a useful conversation.

Refinement becomes difficult when everyone arrives without knowing which items they will discuss. The Product Owner is accountable for effective backlog management, but preparation can be shared with the team.

The Product Owner focuses on product value and the order of work. Before the session, gather:

• A short list of items likely to be considered over the next one or two Sprints.
• Relevant user stories, draft acceptance criteria, mock-ups or user insights.
• Known dependencies and technical considerations.
• An explanation of why these items matter now.

Choose a manageable number of items. Four to ten might work for straightforward changes, while a complex feature could need most of the session. Include people with relevant development, design and testing knowledge.

2. Start With Context

Purpose: Connect the work to a user need or product goal.

Begin with a brief overview of why the selected items matter. One or two minutes may be enough to explain the problem, the evidence behind it and the outcome you want to explore.

Keep assumptions visible. Adding another payment method might help, but an abandonment figure alone does not explain why customers leave.

3. Walk Through Each Item

Purpose: Uncover different interpretations before work begins.

Refinement works best as a conversation. A user story describes a need from the user’s perspective. It gives the discussion a starting point, but it rarely answers every question.

• Who needs this, and what problem does it solve?
• What does success look like?
• What is included, and what is outside the scope?
• Is there a simpler way to meet the need?

4. Improve the Acceptance Criteria

Purpose: Describe the behaviour the team needs to deliver and check.

Acceptance criteria are specific, testable conditions an item should satisfy. They help the team agree what is expected, although they do not replace a conversation or resolve every uncertainty.

One way to write them is using Given, When and Then, a structure used in Gherkin, a language for describing behaviour:

Also discuss failed requests, signed-out users and keyboard access. Record the agreed behaviour where it belongs, whether that is the item’s acceptance criteria or the team’s shared quality standards.

5. Identify Unknowns

Purpose: Make uncertainty visible and agree how to reduce it.

An unanswered question is useful information. Flag it early rather than letting it become an assumption.

• Technical: Do we already have somewhere to store wishlist items?
• Design: How should the wishlist behave on a small screen?
• Privacy or compliance: What data would the proposed payment integration process, and who needs to review it?

If a question needs investigation, create a focused task or a spike: a short, time-limited piece of research. Record the question, the person responsible and the expected outcome. “Confirm whether the existing account service can store wishlist items” is more useful than “Investigate wishlist”.

6. Estimate With Shared Understanding

Purpose: Discuss the likely size of the work and expose different assumptions.

Use the approach that helps your team: story points, T-shirt sizes or time ranges. Story points express relative size using the team’s own scale. Five points in one team does not necessarily mean the same thing in another.

In Scrum, the Developers doing the work are responsible for sizing it. Include the effort needed to deliver and test the item, rather than considering coding alone.

If estimates differ, ask people at the high and low ends to explain their thinking. Planning Poker, where people estimate independently before revealing their choices, can help make those differences visible.

Avoid forcing agreement while significant questions remain. Investigate or split the item, then revisit the estimate. A number does not make unclear work ready.

7. Reprioritise When You Learn Something New

Purpose: Use new information to improve the order of upcoming work.

Refinement can reveal that an item is harder than expected, depends on another change or offers a smaller useful first step. The Product Owner can use that information to reconsider the backlog order.

Refinement informs Sprint Planning. It does not commit the team to a fixed list of work for the next Sprint.

8. Confirm What Is Ready and What Needs Follow-Up

Purpose: Leave with clear decisions and useful next actions.

Before moving on, check whether the team understands the item well enough to consider it in Sprint Planning.

• The user need and scope are clear.
• Acceptance criteria describe the expected behaviour.
• Essential design decisions are available, or outstanding work has a clear plan.
• Dependencies are understood and can be managed.
• Sizing has been discussed where useful.
• The team believes the item can be completed within a Sprint, including the required quality checks.

A readiness checklist is a team practice, not a mandatory Scrum document. Use it to support discussion rather than expecting every detail to be settled before work begins.

Readiness is different from the Definition of Done, which describes the quality standards completed work must meet. For anything needing follow-up, record an owner and when the answer is needed.

• Treating refinement as a reading session. The Product Owner reads each item and everyone quietly agrees. Ask people to explain assumptions and raise questions.
• Bringing unclear or unprepared stories. A wishlist feature with no explanation of who it serves leaves the team guessing. Bring enough context to start the conversation.
• Getting lost in technical detail. Some technical discussion is necessary, but a lengthy database debate can consume the session. Arrange a smaller follow-up when the detail no longer helps everyone present.
• Trying to refine too many items. Rushing through fifteen entries may leave all of them unclear. Reduce the list and focus on the most useful upcoming work.
• Estimating before understanding. Assigning points to a payment integration before reviewing its requirements creates false confidence. Resolve the important questions first.
• Missing hidden dependencies. Third-party approval discovered halfway through a Sprint can delay delivery. Ask what must happen outside the team and who will coordinate it.
• Ignoring information that changes priorities. If autocomplete needs substantial backend work, revisit its position rather than carrying on with the original assumption.
• Leaving out testing perspectives. Include people who can challenge edge cases and expected behaviour, so those questions surface before development begins.

Start with one upcoming backlog item. Ask everyone to answer these three questions:

1. What problem are we solving for the user?
2. What would we need to see to know the item works?
3. What could stop us completing it within a Sprint?

Compare the answers, update the item and assign any follow-up actions. If different interpretations become visible, the conversation is doing useful work.