Myth: Refinement is a required meeting for the entire Scrum team

In this series of posts, we — your Mythbusters Christiaan Verwijs and Barry Overeem — address common myths and misunderstandings. Thea Schukken created the great visuals.

If you prefer, you can also listen to us reading this post.

Is “Product Backlog refinement” a recurring event in your Sprint schedule that happens on a fixed day during the Sprint? Is it something developers slog to with lead in their shoes, mentally preparing themselves for another multi-hour required meeting where a few people talk and most people (pretend to) listen? If so, then this post is for you.

Product Backlog refinement is undoubtedly an essential part of the Scrum framework. But more often than not, it takes the form of a team passively sitting around a meeting table while a subset of the team discusses upcoming items in excruciating detail. Things are not helped by having to wait for that one member with the keyboard to enter everything in JIRA. When doing Product Backlog refinement like this, it is understandable that teams try to spend as little time on it as possible — which is one of the key reasons holding teams back from becoming truly awesome.

In this post, we bust a myth at the heart of why refinement feels like a chore to many teams: the belief that ‘Product Backlog refinement’ should be done as one or more required ‘meetings’ that must be attended by everyone in the team. We also offer alternative approaches that fit more naturally with the development flow.

What does the Scrum Guide say?

The Scrum Guide describes Product Backlog refinement as the act of adding detail, estimates, and order items to the Backlog. It describes this as an ongoing collaboration between the Product Owner and the Developers, and the team as a whole decides how and when to do this.

The Scrum Guide prescribes five required, time-boxed events that happen at prescribed moments during the Sprint: the Sprint Planning at the start of the Sprint to select what the team will work on, the Daily Scrum to synchronize work every 24 hours, and the Sprint Review and the Sprint Retrospective at the end of the Sprint to inspect the results from the Sprint and the way the team collaborated during the Sprint, respectively. The fifth event is the Sprint itself.

So, the Scrum Guide is quite clear: refinement is not an event in Scrum. This may appear like mere wordplay. However, it does have a significant impact on how it is done in the real world. The guide emphasizes that Product Backlog Refinement is something Developers do as a natural part of development. It does not necessarily happen at a fixed moment during the Sprint, which the entire team has to attend. Yet, this subtle distinction is sometimes lost and is one of the reasons why Product Backlog Refinement has become a chore for many teams.

Before jumping into alternatives, let's explore the purpose of Product Backlog refinement in more detail.

The purpose of Product Backlog refinement in Scrum

Scrum is built on the observation that product development is complex. Because of this complexity, better insights and ideas will emerge as we do the work. This means that even the near future is difficult to predict. Scrum provides a lightweight framework for allowing this learning to happen as quickly as possible without losing the focus needed to solve complex problems.

“Scrum provides a lightweight framework for allowing learning to happen as quickly as possible without losing the focus needed for solving complex problems.”

The Product Backlog captures all the work needed for the product that we know of at this time. Some items will be small and clear enough to complete within a single Sprint. Other items will be too big, too unclear, or both. To maximize what we can learn (e.g., from feedback from stakeholders and by simply doing the work) and to reduce the risk of building the wrong product, we want to break down and clarify items to the point where we are fairly confident that we can complete them within a Sprint.

It may be tempting to break down all the work on the Product Backlog to fit it within a Sprint. But a much better use of our time is to break down and clarify only those items we’re about to start work on (say, the next Sprint or one soon after). The time spent on items further down the Product Backlog is wasted mainly as we are bound to learn things that change our views on implementing them or make them irrelevant altogether.

As an activity, Product Backlog refinement has the following purposes in Scrum:

• Clarifying items on the Product Backlog that are too unclear to start work on. This is preferably done directly with the people you’re building the items for (the stakeholders);
• Breaking down items that are too big to pull into a Sprint (which generally also means that they’re too unclear);
• Re-ordering the Product Backlog as needed to make the upcoming Sprints as smooth and valuable as possible;
• Adding or removing items from the Product Backlog as new insights emerge;
• Estimating the effort involved in implementing particular items. This does not have to be as ‘formal’ as assigning story points (an optional practice in Scrum), T-shirt sizes, or whatever sizing technique you use. A gut feeling (“Yeah, we know well enough what needs to be done, and it feels doable in a Sprint”) is fine too;

Items on a Product Backlog are essentially reminders of “conversations that we will need to have in the future.” Refinement is simply the ongoing process of having those conversations. Sometimes, this means talking with stakeholders about some item that may be part of the next Sprint, while at other times, it can be an item that is part of the current Sprint. But instead of this series of conversations that naturally flow from development, for too many teams, it has taken the form of a formalized meeting taking place (only) during a Sprint.

“Items on a Product Backlog are essentially reminders of conversations that we will need to have in the future.”

Try the converge-diverge pattern

For many organizations, ‘meetings’ have become the de-facto standard for integrating and exchanging information within teams and making decisions. In a meeting, we bring as many minds as possible for a given amount of time to achieve a purpose. The assumption here is that this is the best (or even the only) way to tap into teams' wisdom and creativity and share knowledge. However:

• Not all activities related to refinement are ideally suited to do with the whole team. The breaking down or clarification of items, for example, can be done by varying subgroups in the team that then converge back to the team;
• Breaking down items is often complex, requiring significant creativity and time to think through things. Most developers will recognize that refinement can occur during lunch conversations or cycling to work. Meetings are often not the best environment to do this kind of heavy mental weight-lifting;
• There is a natural flow to development during a Sprint. We want to break this flow as infrequently as possible, which is also why the Scrum Guide prescribes only four required events during a Sprint. This minimizes the need for other whole-team events;
• Sitting down around a conference table in a meeting room is not a very engaging way of doing complex work;

Many teams can benefit from a Diverge-Converge Pattern. As a team, decide which items need to be clarified or broken down and who wants/needs to be involved. The smaller groups then do this work during the Sprint or during ‘Breakouts’ (Diverge) and share their results with the team later during the Sprint to decide on the next steps together (Converge). Other activities, like estimation or re-ordering of the Product Backlog, can be done together based on what was learned during refinement. Multiple Diverge-Converge cycles can happen during a Sprint, depending on the complexity of what needs to be refined.

“We believe that many teams can benefit from a Diverge-Converge Pattern to refinement.”

Whatever you do, make sure that refinement remains a collective effort of the team. Although not everyone has to do it simultaneously, everyone should be involved. Having only the analysts or lead developers do refinement is a powerful anti-pattern as it fails to tap into the wisdom of the entire team.

More tips to refine work differently

Rather than spending hours around a table, refinement is an excellent opportunity for the Scrum Master to help the team find different ways to do this:

• Invite the team to form smaller groups responsible for refining particular items during the upcoming Sprint. Let them decide how and when to do this, collaborating with the Product Owner and stakeholders where necessary. Schedule moments where the pairs share their ideas and insights with the team and gather feedback;
• Don’t use tools (like JIRA) during refinement. It’s a massive drain of energy and creativity if people have to wait for that one person with the keyboard to complete typing in a new item. Instead, refine work with post-its or drawings and ask the team to enter it into the tool afterward. If you need to use tools during refinement, make sure that everyone has access to them and can work on them collaboratively;
• Combine Liberating Structures or other facilitation techniques to turn boring refinement sessions into highly interactive sessions where everyone is fully engaged. If you’re breaking down challenging items, invite people to draw the problem. Use 1–2–4-ALL to quickly identify potential strategies or Troika Consulting to give and get help. Use supporting material, like our sheet with 10 potential strategies for breaking down work;
• Invite stakeholders to participate in refinement where needed. To clarify upcoming work and build the right product, you will certainly need their perspective and knowledge;
• Invite team members to decide for themselves if they want to join meetings where the purpose is to break down specific items. Have them determine if they can contribute something to the conversation. If this results in nobody showing up, you have a good topic for the upcoming Sprint Retrospective;
• Experiment with what works for your team. For some teams, doing refinement together is the best way. For others, the above solutions may be more helpful. It depends on the size and experience of the team and its members and the complexity of the domain;
• When using a physical Product Backlog, you can easily add relevant information for refinement. For example, add stickers with a question mark to items that need clarification. Write exclamation marks on items that might become a risk or are important to refine.
• Instead of doing refinement during a meeting, go for a walk outside and use your walk to break down work with your team or subgroup;

Closing

In this post, we busted the myth that Product Backlog refinement should be done as one or more required ‘meetings’ that everyone on the team must attend. We clarified the purpose of refinement in Scrum, offered alternative approaches, and provided some tips to increase its effectiveness.

What’s your opinion about this myth? Feel free to share any other ideas for improving refinement. We’re always eager to learn from you!