Are your refinements messy? This might be why.

Jorrit Kortink
4 min readDec 7, 2022

Recently I’ve been in some refinement meetings that felt less effective than they could be. There’s a lot of engagement, and many questions, which is awesome. But it kind of felt like we were going all over the place.

Disclaimer: in this post by ‘refinement (meeting)’ I mean an event where new work items are presented and discussed by our whole Scrum Team. There are multiple different ways of approaching refinement, and we are still improving. This is one of the approaches we currently apply.

Thinking about why our refinement meeting felt like this, I realised that we were mixing topics and questions that belong in different parts of the refinement process.

Separate What and How refinement

In his article about Refinement Christiaan Verwijs references separating What and How refinement. Having this division ensures that everyone focuses on understanding the context, the problem and the business value first, before moving into how to develop the solution.

I added to that concept by also adding Basic and Deep to the axes, creating a classic 2x2 matrix, known and loved by all.

The flow through the matrix goes from Basic What to Deep What, then Basic How and lastly Deep How. In every stage I’ve indicated which topics, questions or clarifying tools might be applicable to get a work item understood.

Matrix developed by me. For a smooth feeling discussion should flow from Basic What → Deep What → Basic How → Deep How.

Having this matrix might also help understand why sometimes refinement meetings feel like they’re all over the place. It’s possible that they really are. Asking a Deep How question like “What are the specifications of that API?” when the topic at hand is still in the Deep What phase is confusing.

Going back to the high-level problem statement when naming conventions are being discussed is also confusing.

In these examples everyone can see how those questions don’t fit the stage of the discussion. But it happens, maybe because asking the right questions at the right time is a blind spot.

How to use this matrix to make refinement meetings more effective

This matrix can be used in at least two ways:

  1. Creating awareness about the fact that not all questions are created equal. Different questions and topics belong in different stages of the process. Knowing this can help guide the discussion and also help decide when to park questions for later.
  2. It can serve as an agenda or structure for your refinement meetings. After each phase, like suggested in the article above the facilitator can check whether everyone has the same understanding, before moving on to the next topic.

Why understanding the What (and Why) is important

In order to beat the feature factory software developers don’t only need to build what is being asked. Build what is being asked is only focussing on the How.

They need to be able to come up with the best solutions for a problem. And in order to come up with the best solutions they need to understand the problem customers are facing.

Understanding the problem of the customer gives flexibility in choosing different solutions, whereas building what’s asked gives no flexibility. Asking developers to build a feature rather than ask them to solve a problem limits the capacity they are using.

Too often I’ve seen the Why/What being rushed or taken care of by a Product Owner/Business Analyst/Lead Developer, who then pass on the pre-designed solution to the rest of the team.

We need to become better at using the full problem-solving capabilities of all developers, and it starts with explaining context, business value, problem statement, what and why.

Disclaimer two

It’s ok that the process of refinement itself is messy. Different questions pop up for different people at different parts of the process. Not all requirements have the same clarity right from the start. Everything doesn’t fit into a nice and neat little package.

But refinement meetings don’t have to be messy. They can be more effective by recognizing where certain questions or topics fit. By understanding what level of depth is needed at which period in time. Knowing that might help you determine whether ‘right now’ is the right time to bring something to the table.

Conclusion

Next time you’re in a refinement meeting, try to determine in which phase the discussion is, and what kind of questions come to the table. Do they match, or are you all over the place? And how effective does that meeting feel for you? Maybe using the matrix can help.

Photo by cottonbro studio: https://www.pexels.com/photo/green-and-white-lights-5473951/

Further reading about backlog refinement:

What NOT to do during Product Backlog Refinement? | by David Pereira | Serious Scrum | Medium

Mastering Backlog Refinement | by Maarten Dalmijn | Serious Scrum | Medium

--

--

Jorrit Kortink

I write about things that come to mind and that inspire me, probably something about leadership, coaching, or personal development.