How does backlog refinement work in Scrum?

Understanding product backlog refinement

July 31, 2023
Team looking at a whiteboard

Keeping an updated and prioritized backlog is a critical part of Scrum, but it can be overwhelming, especially for a new team. 

Is your backlog refinement meeting taking forever, or maybe just not feeling as effective as it should?  

You can learn to run efficient and effective backlog refinement sessions. This article will cover three key ideas to help you run an excellent backlog refinement session.

  • Understand how a Backlog Refinement helps the Scrum team.
  • Identify how the whole Scrum team participates in the Backlog Refinement.
  • Outline strategies you can use with your Scrum team.
New to Scrum? The Scrum meeting checklist has all the details you need to run effective Scrum meetings.

The Backlog Refinement prepares the Scrum team for effective work.

The backlog is a list of clear and prioritized work for the team. The Product Owner is responsible for prioritizing the backlog to maximize value. The Scrum team is responsible for the clarity, and that clarity comes through backlog refinement.

For the team to deliver maximum value, three things must happen:

  1. Outcomes are clearly defined
  2. Supporting information is visible
  3. Resources are accessible

Outcomes are clearly defined.

During backlog refinement, I often hear the question: “so what do they want?” That question seeks the clarity necessary to avoid later hearing, “that’s what I asked for, but not what I wanted.” 

User stories are helpful in succinct descriptions of the user, their goals and motivations. They should be present in every backlog item along with acceptance criteria. But there is usually additional context that will enable the team to deliver the most value. 

Some possible questions to clarify outcomes:

  • How or where will this be used?
  • How does this functionality need to interface with other parts of the system?
  • How is this the same or different from (this other thing we created)?
  • Are there any design references to illustrate what is requested?

Supporting information is visible.

Have you ever been given a task to do but not the needed information? Maybe a conversation went something like this:

Manager: We need a web page tomorrow. 
Designer: Ok, do you have the copy for the page?
Manager: No, just design it, and we’ll put it in later.
Designer: So, what do you want people to do when they come to the page?
Manager: We’re still figuring that out. We have a meeting set to discuss it next week.

On the surface, this interaction may seem a little ridiculous. But what’s really absurd is how common this conversation is.

The product owner often ends the backlog refinement session with a list of questions they take to track down answers. They add information from these answers to the backlog items so the team has what they need to do the work. Having all the supporting information in the backlog items before they are selected for a given sprint is part of what allows Scrum teams to move with both speed and agility. 

Resources are accessible for work to be actionable

Information isn’t the only resource needed to do the work represented in the backlog items. Does the team have the technology or tools required to do the job? Do they have the skills? The needed resources must be in place before the work is actionable and thus ready for a sprint. 

Maybe a contractor is needed for a given sprint. Or perhaps time should be allocated in a preceding sprint for a team member to receive training for necessary skills or tools.

There may also be design dependencies that would prevent a team from being able to deliver the outcome of a given backlog item. This dependency may affect how the product owner sequences the work in the backlog. The backlog refinement process allows the technical understanding of the dev team to be shared with the product owner and influence the overall roadmap for production.

The whole Scrum team (and friends) participates in the Backlog Refinement.

The backlog is a prioritized list of all known requirements for the product. It’s constantly in flux, and the product owner is responsible for keeping it up to date. The product owner, scrum master, subject matter experts, and development team meet to refine the backlog each sprint. These subject matter experts aren’t part of the Scrum team, but they are invited because their expertise relates to what’s in the backlog.

As they work through items in the backlog, the product owner can introduce and explain them. I let some teams just read what was on the card for a given item and see how well it communicated. This practice helped me see gaps in the descriptions. This clarity is essential because I wanted what was written on the card to communicate effectively when the team selects an item for the sprint.

When reviewing a given product backlog item (PBI), here are possible examples of the conversation:

  • The product owner explains how the feature will impact the user’s experience. Why it’s important and how it relates to the other work the team is doing.
  • Dev team asking about usage, requirements, or needed resources.
  • Subject matter experts provide context for requirements or dependencies.
  • Scrum master reminds the team this isn’t the time to solve the problem. Instead, it's time to identify and clarify it.
  • The whole group works together to write or update the user stories and acceptance criteria.

Some PBIs may be combined or split into smaller tasks as the team gets more clarity. The product owner may choose to reprioritize items in the backlog based on what they learn. 

Usually, the product owner leaves the meeting with a to-do list that may include things like:

  • Documentation to find and attach to a PBI
  • A conversation they need to have with stakeholders about goals, requirements or timing.
  • A meeting to schedule with the Scrum Master to work through the roadmap together.

When run poorly, the meeting involves the product owner reading through all the PBIs and everyone else quietly listening. It’s efficient but ineffective. When run well, there is often robust discussion around key PBIs. It will take longer, and the team probably won’t get through as much as the PO hoped, but there will be actionable clarity on what to do next.

Three approaches to Backlog Refinement

Out of all the Scrum meetings, backlog refinement seems to have the most variety in how it’s run. I’ve tried different approaches on different teams, and I don’t think there is a one-size-fits-all approach. What works best for your team will likely depend on your team's makeup and your type of work.

I’ve outlined three different approaches to holding backlog refinement sessions.

Refine the backlog once a sprint

This approach is the most common and probably a good place to start for most teams. The team has one meeting, usually around the middle of the sprint, depending on how long the sprint is. The product owner will want enough time between the backlog refinement and the beginning of the next sprint to complete any necessary follow-up work.

It’s usually a more extended meeting because the team needs to work through at least one sprint worth of PBIs. The team will start at the top of the backlog and work down. If PBIs have already been covered in a backlog refinement, they will skip them unless the PO has an update on them since the last refinement session.

Refine product backlog items by type.

When I was setting up Scrum for a creative department, the teams were cross-functional in the sense that they included videographers, graphic designers, and web designers. One approach we tried for the backlog refinement was focusing on one type of work at a time. 

We would look at all the video PBIs one after another. This approach reduced the cognitive load from context switching between types of work. The team evaluated the PBIs more effectively by staying in the same category. If there was necessary information on one video PBI but missing on another, the team more quickly recognized the gaps.

After finishing the PBIs for one type of work, the team would switch to another kind. We tried doing multiple types in a single session, and we tried splitting them over multiple sessions. I think that teams did better with smaller focused sessions, but each team will be different. The team will evaluate how they’re working end of the sprint during the retrospective and make adjustments.

Add a backlog refinement session to another meeting.

Scheduling became more of an issue when we split the backlog refinement into smaller sessions. We added the sessions to the end of a Daily Scrum to keep our calendars cleaner. 

It would look something like this. We had 3-week sprints, so we put the backlog refinement session in the second week. (Yes, I know that is a long sprint, but that is another story) So on Tuesday at 9 am, we would have our standup. Then at 9:15, we would shift to a graphic design backlog refinement. I timeboxed the backlog refinement to end at 10 am, though often we would finish early. Then on Thursday, the team would follow the same schedule but with video PBIs. Again it would be timeboxed and end early if we got through all the PBIs.

A word of caution here. The Scrum Master should help the team stay disciplined to keep the two sessions (Standup and Backlog Refinement) timeboxed and focused. Otherwise, it’s easy just to become a more extended catchall meeting. 

Scrum has a lot of meetings and it can be hard to keep them straight, especially when you're getting started.

The Scrum meeting checklist has all the details you need to run effective Scrum meetings.

Related Guides

No items found.

Action Plan

Getting started with Backlog Refinement

I hope this article provided helpful guidance to run efficient and effective backlog refinement sessions. If you want to learn more about Scrum in general, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.

Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 30-minutes coaching session, and we can work together to identify a good next step for you.

Frequently Asked Questions

Scrum events overview

What are the Scrum events?

The rhythm of scrum consists of various events.

  • Sprint planning
  • Daily standup 
  • Backlog refinement
  • Sprint review
  • Sprint retrospective
  • The sprint

The last on the list is sometimes debated as to whether or not it’s actually a scrum event. I include it because it's critical to creating a cadence of work for the team. 

Learn more about the rhythm of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

What scrum events are timeboxed?

Most scrum events are timeboxed relative to the length of the sprint:

  • Sprint planning: 2 hours / sprint week.
  • Daily standup: 15 minutes.
  • Backlog refinement: 2 hours / sprint week.
  • Sprint review: 1 hour / sprint week.
  • Retrospective: 45 minutes / sprint week.

Just because an event has a timebox doesn’t mean it needs to be that long. The timebox is the maximum time allowed for the event.

Learn more about the different scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

When should scrum events be held?

Scrum events are generally held in the following order

The backlog refinement session is unique in that it can be held anytime. 

Explore further the events of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Which scrum event is most important?

I included this because it is frequently asked, but the question misunderstands the importance of the scrum events. It’s like asking which of your limbs is most important. You may be able to answer, but they are really all critical. 

If pressed for an answer, the daily scrum probably has the greatest impact on the team's effectiveness. 

Learn more about the events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Middle of a sprint

What is a daily standup?

The Daily standup is a brief 15-minute daily check-in for the Scrum team to do three things:

  1. Inspects the previous day's work.
  2. Plans the current day’s work. 
  3. Identifies any barriers to getting things done. 

It’s called a standup because it’s so short you don’t need to sit down.

Learn how to keep your team in sync with a daily standup. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

What is scrum backlog refinement?

During the backlog refinement session, the team previews upcoming work to ensure the following:

  • Outcomes are clearly defined.
  • Supporting information is visible.
  • Resources are accessible.

There is flexibility for when to hold the backlog refinement session.

Learn more about how to run a backlog refinement session. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Facilitating scrum events

How to facilitate scrum events?

Scrum events have a clear purpose and agenda but are still very interactive. Facilitation of scrum events is at its best when everyone is engaged, asking or responding to questions. All events are timeboxed, so the facilitator must ensure the team is always moving toward the goal.

Learn more about team member's responsibilities during scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

How to improve scrum events?

Three strategies for increasing participation in scrum meetings are

  1. Clearly state the goal. Sometimes people don’t engage because they are unsure about the purpose.
  2. Use facilitation games. There are many facilitation exercises available for the scrum events.
  3. Invite feedback. Inspection is a pillar of scrum. Ask the team for feedback on what went well and how to improve.

Learn more about everyone’s roles and responsibilities during the scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Who facilitates (or owns) scrum events?

Scrum cultivates shared ownership for all the events, but each still has a facilitator.

Learn more about everyone’s roles and responsibilities during the scrum events. Then explore the most common terms in a Scrum glossary and learn what is Scrum.

Does the scrum master facilitate all the scrum events?

The scrum master primarily facilitates two scrum events:

  1. Sprint planning
  2. The retrospective

The scrum master can help facilitate other meetings while a new team is beginning to learn scrum.

Learn more about roles during scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Scrum events purpose

What is the goal of each Scrum event?

  • ‍Sprint planning: Clarify the direction and goal for the sprint. 
  • Daily standup: Everyone on the team gains updated visibility into everyone’s work. 
  • Backlog refinement: Understand upcoming work.
  • Sprint review: Present finished work to stakeholders for feedback.‍
  • Sprint retrospective: Review how the team works and make necessary adjustments.

Understand the purpose of the scrum meetings. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Which scrum events facilitate inspection and adaptation?

Inspection and adaptation (along with transparency) are pillars of scrum, so all events involve them.

  • Sprint planning: the purpose and work of the sprint are inspected.
  • Daily standup: progress toward the sprint goal is inspected, and adjustments are made.
  • Backlog refinement: upcoming work is inspected, and PBIs are adapted.
  • Sprint review: delivered work is inspected, and upcoming work is adapted
  • Retrospective: team health and interactions are inspected, and norms or plans are adapted.

Learn more about the role of events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Which scrum event is for process improvement?

Process improvement aligns closely with the scrum pillars of transparency, inspection and adaptation.

  • Sprint planning: How do we improve the product?
  • Daily standup: How do we improve our approach to the sprint goal?
  • Backlog refinement: How do we improve the quality of the product backlog?
  • Sprint review: How do we improve the functionality being delivered?
  • Retrospective: How do we improve how our team works together?

Out of all the events, the retrospective is the most focused on process improvement.

Learn more about events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

What is the goal of the scrum of scrum event?

The scrum of scrums is an extra scrum event used when multiple scrum teams are collaborating together on a single product.

The scrum of scrums follows a similar pattern to the daily scrum session. The session allows the teams to update each other on what has been done, what obstacles have been encountered, and what to do next.

The scrum of scrums allows those teams to stay in sync and account for dependencies that bridge across teams. When facilitated well with healthy teams the scrum of scrum can even create collective ownership you see in self organizing teams.

If multiple scrum teams are collaborating on a single product then ideally both teams care more about it the product as a whole succeeds versus just caring if they did their part. The transparency, evaluation and adaptation from the scrum or scrums can make this possible.

To learn more explore the most common terms in a Scrum glossary.

Ready to level up your company? Get in touch today!