Refinement: The Mise en Place of Great Scrum Teams

And five helpful strategies to make it more effective as suggested by our patrons.

You can also listen to a podcast version of this post here.

Does refinement in your team feel like a slog? Do developers go there with lead in their shoes? Many Scrum Teams struggle with refinement, and understandably so. Yet, in many ways, this is where some of the most important work happens. And some of the hardest work.

In this post, we offer a reflection on the purpose of refinement. And we offer recommendations to make the process more enjoyable and effective — many of which originate from a discussion we had with experienced Scrum Masters on the Discord server that is accessible to our patrons.

The purpose of Refinement

Product Backlog Refinement exists, first and foremost, to break down large chunks of work into smaller chunks of work. As with everything in the Scrum Framework, this makes it easier to work empirically. If we would work on large items — that take weeks or even months to complete end-to-end — we would be unable to get frequent feedback from our actual stakeholders. This introduces the significant risk that we make incorrect assumptions about what stakeholders need that, once falsified, require us to go back and change everything.

Very big items don’t flow very well. They also require poster-size stickies

So instead our aim with Scrum is to more frequently deliver smaller chunks of work so that our stakeholders can give us meaningful feedback that spurs new ideas, changes to what has already been done, or uncovers bugs that need to be addressed. In short, delivering small bits of work is a great way to help us think and understand what is needed.

So what objective evidence do we have to support these claims? Schön and her colleagues (2017) found that refinement was considered one of the harder challenges for Agile teams. Unfortunately, little systematic research has been done in this area. But from the correlational data we’ve collected with the Scrum Team Survey (roughly 1.200 teams), we can clearly see that teams that release more frequently also have more satisfied stakeholders and experience higher morale. In turn, the data shows that teams that engage more in refinement are more capable of releasing frequently. Learn more in Verwijs & Russo (2021).

All the work on your Product Backlog should eventually be refined to make it small enough — but only when you’re about to start work on it in a coming Sprint. When something is “small enough” depends very much on your context. But as a starting point, your team should refine to a degree where they can comfortably select and complete multiple items in a single Sprint. Experienced Scrum Teams will tell you that smaller is generally even better.

Focus your efforts on the coming Sprints, not too far into the future. Although the length of Sprints varies by team, I assume Sprints of a week for this image. When Sprints become longer, it becomes increasingly wasteful to focus that far into the future (say months)

We like to think of refinement as the process of mise en place that experienced cooks use to improve the flow of their cooking. Instead of cutting and organizing your ingredients while you are cooking, mise en place is when ingredients are put in place and prepared (cut, diced, halved, stripped) before the actual cooking. Without mise en place, cooking is often stressful and chaotic as you are effectively doing two things at the same time. We can tell you from personal experience that doing both at the same time may work sometimes, but it just as easily ends up with burned food, forgotten ingredients, cut fingers, and a kitchen that looks like a warzone — especially as the meals become more complicated and the groups larger.

“We like to think of refinement as the process of mise en place that experienced cooks use to improve the flow of their cooking.”

So refinement, like mise en place, exists to organize and prepare your ingredients for development. The point is not to refine everything on your Product Backlog; that would be just as wasteful as cutting up and preparing ingredients for months of cooking ahead of time (and then having to throw away most of it because you didn’t need most of it). Most ingredients you can prepare just before cooking. At the same time, some ingredients may benefit from earlier preparation. For example, some items on your Product Backlog may involve research or interviews that need to be done as part of the refinement. This constant balance between what to refine now and what to refine later is what distinguishes experienced Scrum Teams from starting Scrum Teams.

Refinement is the mise en place of product development

Refinement is what great developers do naturally

Consistently, I’ve found that great developers naturally refine their work and enjoy this process of strategizing, organizing, and breaking down work. In fact, we strongly believe that the skills for refinement are the most important ones for developers to acquire. It is what distinguishes a developer who remains stuck in a large blob of spaghetti code for days from a developer who decomposes a problem into smaller classes and sub-components, and solves each of them separately. Many experienced developers enjoy this process of decomposition — or refinement — because it presents them with an intellectual puzzle to solve; an opportunity to demonstrate their craftsmanship and come up with clever ways to break down work. In another post, we compiled 10 strategies to decompose work that I’ve always found helpful as a developer.

Don’t use refinement for …

If we keep the purpose of refinement firmly in mind, there are a couple of things that many teams do that are not so helpful:

1. Don’t use refinement to generate estimates for forecasting; we believe that this is a huge waste of valuable time. You can only forecast complex work by doing it, not by estimating it. Developers are acutely aware of that reality and will grow to hate “refinement” if this is what you use it for — and for good reason.
2. Don’t use refinement primarily to “write user stories” or perform data entry into JIRA. While it is a great idea to capture the insights that emerge from refinement, the conversation really is the more important part. We write more about this here.
3. Don’t default to a once-a-Sprint “refinement meeting” that has to be attended by the entire team. The puzzles of refinement (“how do we break this down further?”) often need to be mulled over for a while, and you can’t timebox that to a single meeting. It is far more helpful to understand refinement is an ongoing activity where developers strategize, organize, and prepare the work for the upcoming one, two, or three Sprints. Some of this happens with Product Owners and stakeholders, some with one or two developers, and some by the entire team. We write more about this here.

The gist of these “don'ts” is that they draw time and energy away from solving the creative puzzle of how to break down large chunks of work into smaller chunks of work. It also removes opportunities for developers to appreciate the creative and intellectual challenges of decomposition, and how it makes them better developers.

Five suggestions to make refinement more effective

So what are the options to make your refinement more attuned to its purpose? A conversation between experienced Scrum Masters on our Discord server for patrons resulted in the following recommendations.

1. Separate “How?” and “What?” refinement

Sarah Gruneisen recommends separating refinement into multiple sessions that either focus on the “What?” or the “How?”. The “What?”-sessions are attended by the Product Owner and developers. Each item that the Product Owner has in mind for the coming Sprint is briefly presented (its purpose and why it is valuable to users), after which the developers use a consensus vote to determine if they understand the item sufficiently or not. The team works hard to stay out of the solution space and focuses these sessions on how an item should work for users and how it is valuable to them. When the consensus vote doesn’t result in a clear “Yes”, a Q&A round is initiated where the developers generate and ask questions to the Product Owner to clarify the item until the vote passes. Each item that passes the vote is marked for further “How?”-refinement.

The “How?”-refinements generally take place without the Product Owner and focus on the technical and functional solutions that come to mind for the developers present. One by one, the items selected for refinement are read, and, once understood, each developer silently thinks of and adds solution possibilities to a shared list. When everyone is done, each developer presents their solutions, and those present vote to pick one preferred solution. Depending on the size of the item, the session then proceeds to further refine that item into sub-items and potential solutions for those sub-items. Everyone present can suggest rewordings, changes, or further breakdowns. One or more of these sessions are organized during a Sprint.

Sarah adds: “This method works really well for the team as the introverts are not pressured. Everyone gets a chance to solve the puzzle. We then discuss it as a team without interrupting each other. Everyone feels part of the solution”.

2. Start from the end

Another way to keep refinement focused on its purpose was shared by Sven de Koning. He likes to ask developers to start at the end; if this item would be implemented, what would it look like to a user? What would we show to users during a Sprint Review to get their feedback on? This presents the Product Owner with a great opportunity to see if everyone is on the same page. From this shared understanding, the team then works backward through the various steps and interactions that need to be implemented from the user’s perspective. For each individual step and interaction, the team considers if they are absolutely critical to the item under refinement, or if they can potentially break down the item into smaller bits there. For example, some items may involve certain user flows or unhappy paths that are not critical to the item, or could feasibly be implemented in a simpler way for now while spinning off the more complex variant as a separate item for the Product Backlog.

3. Multiple diverge/converge flows

Multiple Scrum Masters — like Remco Hogenbirk and David Fox — suggest to organically refine during Sprints by introducing multiple opportunities for the team to converge and then diverge into small sub-groups (or even individuals) for more specific refinement. So during a shared session, the team agrees on what to focus their refinement on and then diverges into smaller sessions (asynchronously via Slack, synchronously on Zoom, or even individually) to refine the items further. The team reconvenes later during the Sprint to see what else needs to be refined.

4. Refine with the Product and Sprint Goal in mind

Instead of simply refining what is at the top of your Product Backlog, always start by inviting the Product Owner to clarify the objective for the coming Sprint. What is a valuable goal they would like to achieve that Sprint? And how does it tie into the larger Product Goal?

This goal-focused refinement prevents hodge-podge refinement of whatever may be currently at the top of the Product Backlog, but may not ultimately matter to the objective of the next Sprint(s). It is also entirely likely that refinement results in important insights that influence, change, or inform what the objective for this and upcoming Sprints should probably be.

5. Use Liberating Structures to engage everyone

Liberating Structures are super simple “microstructures” to make your interactions as a group more engaging. Their purpose is to create an environment where every voice and perspective can be included, and that makes them ideally suited for refinement. Here are two suggestions:

• Use the Liberating Structure Celebrity Interview to let developers interview the Product Owner about the items they have in mind for the next Sprint. Then follow-up with a 1–2–4-ALL to generate solutions and potential breakdowns, and use 15% Solutions to determine how everyone can contribute to refinement through the Sprint.
• For tougher items, use a Liberating Structure like 25/10 Crowd Sourcing to gather a lot of ideas (anonymously) that might help break it down. Or invite developers from other teams and run either a Troika Consulting or a Wise Crowds. This is also a great opportunity to develop those refinement skills together.

Closing Words

Yes, refinement is hard and challenging for many Scrum Teams. So far, my experience is that this often goes back to how refinement is understood by teams. More often than not, what makes refinement such a slog is when it is solely spent on writing stories, estimating story points, and endless meetings where only a few people talk (and the rest sits and waits until it's over). In this post, we shared both a reflection on the purpose of refinement and five practical suggestions to make it more effective.

We very much want to thank all the patrons who shared their thoughts on this challenge. It also demonstrates how our growing community of patrons is eager to help and support each other. If you’d like to contribute, you can support our community at patreon.com/liberators.

Download our free cheat sheet with 10 helpful strategies for breaking down large items. Or get this fully prepared 90-minute string of Liberating Structures to refine large and unclear items with your stakeholders.

Support us so we can create more content like this. See patreon.com/liberators for more information

References

• Schön, E. M., Winter, D., Escalona, M. J., & Thomaschewski, J. (2017, May). Key challenges in agile requirements engineering. In International Conference on Agile Software Development (pp. 37–51). Springer, Cham.
• Verwijs, C., & Russo, D. (in press). A Theory of Scrum Team Effectiveness. arXiv preprint arXiv:2105.12439. Direct link.