Refinement demystified: turning tedious meetings into meaningful outcomes
It’s Tuesday afternoon. On the 11th floor of an office in Amsterdam, a team gathers in a meeting room. After a brief check-in, they’re all eager to start their refinement session. Following a short discussion on priorities, they pick an item from the list to begin their elicitation. Opening the conversation, the lead developer says: “This item is all about... eh...” From that moment, the meeting starts to derail a little. Nobody knows exactly what was originally meant by the item and the description isn’t as clear as it appeared when it was entered into the workflow system a few weeks ago. Discussions diverge from their initial purpose – what’s truly needed and whether other items might be more urgent to address.
Is this familiar to you? It is to me. Many times, in multiple organizations, I’ve seen teams struggle with getting clear on what to work on. Refinement isn’t just a mainstream practice in Agile organizations; in non-Agile organizations, too, it’s key to have an understanding of what needs to be built and when something is good enough. Regardless of the approach you’re following, refinement is a good practice to get the most out of your development. That’s why I want to shed some more light on this practice and share a few tips on how to make the most of it.
More than a meeting
Refinement is the process of preparing the items on the product backlog for future iterations. Large chunks of work, like releases or epics, are split into smaller items that the team can work with. Whatever method of development you adhere to, it’s a crucial process with many advantages.
In many organizations, refinement is seen as a meeting. While it’s important for the whole team to agree on the proposed solution – and a meeting with the entire team might be useful – conducting all refinement in a single meeting isn’t ideal. Why settle for long, tedious discussions with the entire team if you don’t have to? If you treat refinement as a process – a sequence of meetings, small conversations, sparring with subject matter experts and even desk time – it becomes significantly more efficient.
Treating refinement as a process also enables different people to work in their preferred style and pace. The approach can be aligned with the type of epic, feature or user story. For instance, one developer may prefer to think and document at length, while another might prefer lively discussions at a whiteboard. Some items may require technical input from experts (eg security or compliance), while others might involve user-centric sparring sessions with end-users. During a time-pressured large-group meeting where all items are treated the same, subtle nuances can easily be lost.
That said, the backlog refinement meeting is still a key moment in the process. Since the entire team is responsible for the work completed during an iteration, it’s essential that all members agree on the proposed solution, the testing approach and the item size. Backlog refinement is a team effort, and the meeting has two main outputs: a set of items that meet the Definition of Ready (DOR) and are ready for the next iteration, and an updated product backlog.
Preparation is key
When you’re in a meeting with most or all the team members, focus on what the meeting is aimed at: refinement. That means the team works to find the best way to implement a solution. Avoid talking about topics that don’t belong in a refinement meeting. Don’t give status updates or discuss planning, but focus on defining the best implementation.
“I’ve been listening to your discussion for ten minutes now,” I say, interrupting the meeting. “I heard a lot of talk about process, received some status updates and listened to a debate about whether this last item fits into the next iteration. How much time do you think you’ve spent talking about the solution?” The participants fall silent. After a moment, the scrum master speaks up, reluctantly, “I think we didn’t talk about the solution at all.”
Refinement, as a process, is a series of activities: thinking, writing, reviewing, discussing and preparing. “Preparing?” Several team members chuckled when I explained how to increase the impact of their meetings. “We don’t prepare for our refinement meetings,” they admitted. But preparation can make all the difference.
Determine beforehand what items you’re going to discuss in the next refinement session, and decide who’ll work on which item. For example, one team I coached determined at the end of every refinement meeting who was going to prepare which items for the next meeting. I think we all concluded that it worked great.
It’s okay if one developer or business analyst takes the lead in defining a user story and proposing a solution. When refinement is treated as a process, this preparation can happen well before or between refinement meetings. This gives other team members and stakeholders enough time to get involved. Stakeholders can read the user story at their own pace and share their thoughts. Those thoughts can then be discussed in the next refinement meeting. By rotating the tasks to prepare items, team members who are usually reluctant to speak or participate in the preparation can stand up and pitch their solutions during a meeting. You might be surprised by what they come up with.
Full potential
Backlog refinement is more than just a meeting; it’s a process that, when done well, can transform how teams collaborate, prioritize and deliver value. By viewing refinement as an ongoing series of activities rather than a single event, preparing effectively and focusing on solutions, teams can unlock their full potential and reduce inefficiencies. The key is to involve everyone, leverage diverse expertise and create an environment where thoughtful preparation meets meaningful discussion.