Endless and boring Product Backlog Refinement meetings
How to break this hamster wheel?
A few Sprints into building a new product, the team starts to feel that they are struggling with regards to the process and practices required to deliver a potentially releasable product increment. One of which is Product Backlog Refinement (or “Refinement”) meetings - where the whole team gets together so a few of us can talk about the upcoming PBIs, while the rest listen passively to these discussions.
If an item has a low estimate, we won’t worry about it again until Sprint Planning. If not, the same item is discussed again and the cycle repeats, as we often have gained little to no new knowledge about them between those Refinement Meetings. Still no progress in coping with uncertainty and lack of knowledge? Easy, we will plan a spike to do in the next Sprint.
Those meetings feel repetitive, exhausting, and boring overall with “little to no value” for most of us. Does this sound familiar? I’ve got good news for you: it doesn’t need to be this way. We can do better!
What should we consider to do during the refinement?
What does the Scrum Team usually do during refinement and what does that look like? In my experience, the Scrum Team runs one or two refinement “meetings” during a sprint, where the members:
- usually rewrite the PBI and/or add some acceptance criteria to it,
- sometimes split into separate “smaller” PBIs,
- and add known sub-tasks that grasps what work we need to do.
But is it everything we can and should do during refinement? Let's examine what the Scrum Guide says about it:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. [1]
So, Product Backlog Refinement shouldn’t only be a meeting session. While in most cases it manifests like that, at its core, it should be an ongoing process, an activity, which can happen at any time. Let’s analyze this description more deeply:
The detail
Product Backlog refinement is the act of adding detail (…) to items in the Product Backlog. [1]
What is a detail? Think about it for a second. Is it only to write down a description? Or when we add some acceptance criteria to PBI it is a detail too? What about sketches, designs, known edge cases, external dependencies, data that backs up the idea, are those details to be added too?
The estimate
Product Backlog refinement is the act of adding (…) estimates (…) to items in the Product Backlog. [1]
Here it should be easier, as the Scrum Guide is specific about who should do it:
The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate. [1]
and a side note:
More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. [1]
But how, when, and in what units should we estimate? Should it be in Story Points, in time units, T-Shirt, man-days, etc.? If you estimate, do you know the purpose of that estimation? Why even bother with that question: How many hours/points is it?
The order
Product Backlog refinement is the act of adding (…) order to items in the Product Backlog. [1]
It is rather straightforward, as the Scrum Guide says:
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
(…)
- Ordering the items in the Product Backlog to best achieve goals and missions; [2]
But also two side notes here:
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. [1]
and
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. [2]
In other words - the Development Team may order the items in the Product Backlog on Product Owner’s behalf. Nevertheless, the Product Owner remains accountable for that this order reflects how to best achieve goals and missions.
Summary of all the points above:
- Refinement is an ongoing process, not “one meeting” in a sprint.
- In fact, PBI can be refined without any meeting at all. You can add the details, estimates, order, etc., during the Sprint without a meeting as the team members figure out what needs to happen on the go.
- You perform an act of refinement each time you add such a detail, whether or not it is a rewrite of the initial PBI, when you add more insights such as acceptance criteria, edge cases, data, sketches, designs, etc.
- You perform an act of refinement each time you change the order of items in the Product Backlog.
- You perform an act of refinement each time you add an estimate to PBI.
Why do we do refinement?
Let’s assume that we know more or less what to do “during refinement”. Do we also know why we are doing it?
Consider this fragment of the Scrum Guide:
Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box.
Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. [1]
What does “Ready” mean anyway? When you are learning to take an assessment or exam, when do you consider that you are “ready” to take it? More likely you do it when you feel confident enough that you are prepared well and the risk is not overwhelmingly high to give it a shot and you can accept that risk.
Perhaps we can say that:
By the act of refinement of Product Backlog Items, we strive to cope with uncertainty and to reduce the risk, so that we can work on considered items with more confidence within current and upcoming Sprint(s).
Endnote
It is good to have an opportunity to assess the top of the Product Backlog with the whole team within a “refinement meeting”. It is a perfect place to hear a wider voice and focus on what’s next as a team, but we should remember that it is not everything.
It is perfectly fine if, during the sprint, the Product Owner and different Development Team members collaborate in smaller groups together, or even sometimes alone, to refine upcoming PBIs.
We should trust each other and remember that we should have the courage to work on tough problems and respect each other to be capable, independent people. Those are two out of five Scrum Values that we may recall here, if not more [3].
Experiment with Refinement
I encourage you to challenge your approach to Product Backlog Refinement. There is no silver bullet on how to do it, and definitely, a single or couple of meetings where only some people talk and other passively listen is not the finish line here. In the end:
(…) The Scrum Team decides how and when refinement is done. (…) [1]
So go, try more things, some new unique ideas, and find your way. Maybe you can do more than simply rewrite the initial PBI description?
Source:
[1] the Scrum Guide, Nov 2017, page 15
[2] the Scrum Guide, Nov 2017, page 6
[3] the Scrum Guide, Nov 2017, page 5
