Silent backlog refinement meetings: a more effective Agile meeting

Backlog refinement is a fundamental part of for good Agile. But if you are like many teams, you don’t spend enough time doing it. Silent meetings is a new and effective method that is definitely worth a try. 

Let me quickly walk you through how you can implement them in your organization. 

But first:

Backlog refinement itself is challenging

Refining your backlog is a science in itself. Doing it well has many challenges, such as:

• How to involve everyone 
• How to have prepared optimally 
• How to have productive discussions and get the whole team to share their valuable input during the meeting
• How to do all this efficiently, to not take too much time away from “actual” work

Remote meetings add to the challenges

Online meetings have made the situation even more challenging. In online meetings, it is difficult to communicate efficiently. One person is speaking, others are (maybe) listening (or maybe they are doing something else). Often, certain people (you know who they are) go on and on for far too long, since they don’t get the visual cues from others that it’s time to move on.  

Silent meetings - a simple method to solve these challenges

Silent meetings have evolved to solve the problems of traditional meetings. In a silent meeting, you focus more on reading, thinking, and commenting on material that has been prepared before the meeting. 

After all, reading is:

• A much faster form of communication than talking and listening. 
• Much more democratic - introverts or non-native speakers are not as easily dominated by vocal extroverts.

This makes the silent meeting method perfectly suited for backlog refinement. Engineers are used to reading and commenting. And there are quite a few introverted engineers out there. 

What silent backlog refinement meetings are

Let's first look at the basics of silent meetings. And then later we will look at how you can apply them to backlog refinement meetings specifically. 

Silent meetings consist of:

1. Agenda (meeting goals, non-goals, process, and facilitator)
2. Table read
3. Reading and commenting
4. Facilitator synthesis, conclusions, or a summary

Silent meetings may not be totally silent - more like 95% silent. Participants can still speak when needed. But most of the meeting communication is done by reading, commenting, and adding to the work item you are constructing.

The table read

Silent meetings only work if there is a starting point. A traditional meeting may start by someone giving a PowerPoint presentation. Silent meetings should start with a table read instead. The table read is a written narrative. The silent meeting manifesto calls for a 4-6 page narrative.

Applying the table read to silent backlog refinement

The table read for refinement could be a user story that has been prepared by the Product Owner or any other team member. 

The story would still have the: 

• Title
• Story description 
• Additional information 
• Acceptance criteria (these are important - more about them here)

There could also be a narrative added, but it is not mandatory. You can even use silent refinement to analyze epics or even initiatives. When you do any of those, it makes even more sense to use a longer written narrative.

The silent backlog refinement process

Use a tool that allows each participant to instantly see other people’s contributions. Jira is not great for this. Better options are Confluence (in co-edit mode), Miro boards, or similar online whiteboard tools.

You are not running a monastery though, in some parts of the discussion, you may have to speak. There could be questions or comments that are too complex to write. But the team should strongly resist talking and prefer writing and reading.

Before the silent session, the team should agree: 

• Which tool to use.
• A writing format to add additional clarifications, comments, and questions to the story. 
• How to notate: How to express agreement or disagreement to anything that is written (thumbs up, stars at the end of the line, or similar).
• How to signal that the team is ready to move on to effort estimation. This could be a timebox (5 minutes per item) or the facilitator notices no more edits happening.
• How to estimate effort for an item (e.g. with a special tool, Miro board add-on, or a chat vote simultaneously)

Here is my notation suggestion:

• Do not understand - question mark: “?”
• Like, second, agree fully - star: “*”
• Strongly disagree - exclamation mark: “!”

How to run a silent backlog refinement meeting 

Before the meeting

1. The Product Owner collects stories to be refined, in the tool you are using 
2. The stories are prepared beforehand by someone (table read) (see here why that is so important) 

In the meeting 

1. Controlled by the facilitator, one at a time, the team reads (silently!) through the story description 
2. The team edits, comments, asks questions, agrees, and disagrees on the topic at hand
3. The facilitator notices that editing slows down (or an agreed timebox limit is reached)
4. The team estimates the effort, for example by playing planning poker 
5. You move to the next item on the agenda

In short: Why the silent meeting method is perfect for backlog refinement

Not only is this kind of backlog refinement significantly faster and more efficient:

• It forces the team to prepare the backlog items for refinement (to have the table read). 
• It automatically documents the refinement discussion into the item. 
• It is a much more democratic way of discussing, allowing less vocal and junior team members to express their opinions more freely. 

I am not saying this practice suits everyone and every team. But give it a try, experiment with it or components of it, and see for yourself.