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.

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. 

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.