Skip to main content

Experiment: Try the Converge-Diverge Pattern to Improve Refinement

October 13, 2024
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? 

Product Backlog refinement is undoubtedly an essential part of the Scrum framework. However, it more often than not involves a team passively sitting around an (online) meeting table. In contrast, a subset of the team discusses upcoming items in excruciating detail. 💤 

Items on a Product Backlog are reminders of conversations we will need to have in the future. Refinement is simply the ongoing process of having those conversations. Instead of making these conversations naturally flow from development, for too many teams, they have taken the form of formalized pre-scheduled meetings. ⏰ 


Not all refinement activities are ideally suited to the whole team. For example, breaking down or clarifying items can be done by varying subgroups within the team that converge back on 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 for heavy mental weight-lifting. 🏋‍♀️ 

We've experienced teams benefitting from a Diverge-Converge Pattern. 
1️⃣ As a team, decide which items need clarification or breakdown and who wants/needs to be involved. 
2️⃣ 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). 
3️⃣ Other activities, like estimation or re-ordering of the Product Backlog, can be combined based on what was learned during refinement. 
4️⃣ Multiple Diverge-Converge cycles can happen during a Sprint, depending on the complexity of the refinement task.

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.

Try to make this part of the team's natural development flow. Make it an ongoing activity, not a fixed event. 

Why don't you give it a try? We believe that doing refinement - in such a lightweight manner - like this matches the purpose of Scrum itself:

Scrum provides a lightweight framework for learning as quickly as possible without losing the focus needed to solve complex problems.

Any other thoughts or ideas to improve refinement?

What did you think about this post?