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

Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve complex problems using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out theprevious episodes here.

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

Is “Product Backlog refinement” a recurring event in your Sprint schedule, happening on a fixed day during the Sprint? Is it something that 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 certainly 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 Scrum Teams back from becoming truly awesome.

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

What does the Scrum Guide say?

The Scrum Guide describes Product Backlog refinement as the act of adding detail, estimates and order items in the Product Backlog. It goes on to describe that this is an ongoing collaboration between the Product Owner and the Development Team and that the Scrum Team as a whole decides how and when to do this.

The Scrum Guide prescribes five required, time-boxed events that happen on 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. But it does have a significant impact on how it is done in the real world. The guide emphasizes that Product Backlog Refinement is something that Development Teams do as a natural part of development. It is not something that necessarily happens at a fixed moment during the Sprint where the entire Scrum 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 Scrum Teams.

Before jumping into alternatives, lets first explore the purpose of Product Backlog refinement in a bit 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’re doing 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 for solving 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. While 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 go ahead and break down all the work on the Product Backlog to make it fit within a Sprint. But a much better use of our time is to break down and clarify only those items that we’re about to start work on (say next Sprint or one soon after). The time spent on items further down the Product Backlog is largely wasted as we are bound to learn things that change our views on how to implement 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 to integrate and exchange information within teams and make decisions. In a meeting, we bring as many minds into the room as we can 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 the wisdom and creativity of teams and to 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 a complex activity requiring significant creativity and time to think things through. As most developers will recognize, refinement can also take place 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;

We believe that 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 Scrum Team at a later moment during the Sprint to decide on next steps together (Converge). Other activities, like estimation or re-ordering of the Product Backlog can then 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 at the same time, everyone should be involved in it. 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 Scrum Team to form smaller groups that take responsibility for the refinement of 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 Scrum Team and gather feedback;
• Don’t use tools (like JIRA) during refinement. It’s a huge 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 afterwards. If you really need to use tools during refinement, make sure that everyone has access to it and can work in it 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. In order to clarify upcoming work and to 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 maturity of the team and its members and the complexity of the domain;
• When using a physical Product Backlog you can easily add information that is relevant 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 items 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 must be attended by everyone in the team. We clarified the purpose of refinement in Scrum, offered alternative approaches to do refinement and provided some tips to increase the effectiveness.

What’s your opinion about this myth? Feel free to share any other ideas to improve refinement, we’re always eager to learn from you as well!