6 Practices to Refine Your Product Backlog Refinement
Product Backlog Refinement (PBR), or simply Refinement, is an activity, first and foremost, to create actionable Product Backlog Items, typically by splitting big fuzzy items into smaller actionable chunks. Refinement is a multi-team session with Product, business people, and all related stakeholders as needed.
Teams typically have a scheduled cadence every 2 weeks for Refinement, but depending on the needs, the Product Owner can call an ad hoc refinement session.
The primary activities in PBR are:
- Splitting big, fuzzy items
- Clarifying items until teams feel comfortable to start, preferably without further “what” questions
- Estimating size, “value”, risks, and so forth
So, in a nutshell: split, clarify, estimate.
Practices for better refinement session
Since late 2021, teams have been doing big group refinement numerous times. Through some trial and error, there are several practices that we generally found to be useful in conducting a good refinement discussion.
Note that the list below is not intended to be complete, nor is it a mandatory process to be followed. We expect teams to try it out in practice and over a period of time to experiment with variations and/or add new practices. The only rule is to experiment and improve.
1. Multi-Team Session with Diverge-Converge flow
It typically started with a PO sharing the objective of the Refinement and what prioritized items are there to be refined and discussed. Teams then arrange themselves in 3–4 mixed groups, each about 6–10 ppl, and items are then spread to those groups.
A mixed group includes representatives from each team within a clan and also product, business people, and other stakeholders related to an item being discussed.
Facilitators will diverge the conversations into small mixed groups. After a time-boxed discussion, they will converge the conversations and ask each group to share what they discuss with the bigger audience. This is done in 2–3 rounds, with each round taking, on average, about 30–45 min.
Since we work remotely, we use a virtual gathering tool where people can walk around in their avatars. This makes it easier since people can just “walk” to a mixed group without needing to have a facilitator assign people to breakout rooms
2. Prompts
The simplest yet quite effective practice, Prompts are opening questions that trigger discussions. For example, the typical Prompts that we use are:
- What do we know now?
- What do we not know?
- What are the scope/boundaries?
- Are there any dependencies on other Clans/Tribes?
- What are the risks of not doing this?
Sometimes, the gentlest nudge may yield the biggest results.
3. Take a Bite
In big organizations, there is a mental model that assumes all details of a project/feature/initiative can be conceived at the beginning, so we tend to see things more toward the left side of the picture above.
In reality, digital product development has a lot of inherent complexities and uncertainties. In discussing requirements and scope, all-at-once thinking (left side) might not be the best approach, as we do not know all the details. Doing partial splitting, on the other hand, would be a better approach as it results in a high-level split based on some sensible assumption that is collectively agreed upon by all related parties. And from there, we take a bite, meaning we take a relatively small item that, when delivered, provides either one of these 2 things:
- Deliver potential value for the customer
- Help us to understand the problem better
When and How do we take a bite?
Generally, it’s done in Product Backlog Refinement with other team members and PO. But any team member can do this in other events as well, as long as the PO is informed.
There are multiple ways to take a bite, but typically, splitting/taking a bite is done based on the following:
- Services/components (🙅 not recommended but relatively easy to do)
- User journeys (👍 recommended but relatively harder to do)
- Key examples/scenarios (👍 recommended but relatively harder to do)
4. User Story
⚠️ User Story is one out of many ways to describe a Product Backlog Item. Not every Item is a User story, nor every item needs to be written as a user story. Use your own discretion and consider your context when practicing this method.
A user story is a very brief description of what the system does for its users to help them perform their work more easily, written from the user’s viewpoint.
User Stories are intentionally short and high-level because it is an invitation for discussion. We expect details to emerge from collaborative discussions with the teams and stakeholders in refinement, and then those details can be captured as and when the need arises.
The typical format to use would be as follows:
IN ORDER to [need/motivation], I WANT TO [action] from my [product]
or
AS A [persona/end-user], I WANT TO [action] from my [product], SO THAT [need/motivation]
For example:
5. Flow Visualization
Simple visual diagrams can invite participation. We prefer simple, quick-and-dirty hand-drawn (or mouse-drawn) diagrams in this case.
Typical diagrams used are:
- User Flow / User Journey
Searching “User Journey diagram” online will show many sophisticated customer journey maps. For the context of the refinement discussion, usually, your best bet is to have a simple customer flow diagram using stickies and arrows.
The above is one quick example to start the discussion. Note that it is a very high-level diagram with no details. We want details to emerge from multiple discussions progressively.
- Use Case Diagram
- Mindmap Diagram
6. Specification by Example
First, let’s start with what Specification by Example (SBE) is not:
- SBE does not mean everything is written down in GIVEN WHEN THEN
- SBE does not mean a tester writing down specifications in isolation
SBE, or also known as A-TDD or BDD, is about collaboratively defining and clarifying business-oriented functional tests/ requirements using realistic examples instead of abstract statements. The goal is to increase collective understanding, and tests are the means of getting there.
Development Team, Product people, and Designers must be involved in the process, but this technique will have way more impact if it is understood by other parties, such as business people and subject matter experts.
A nice explanation of the importance of specifying through examples from Gojko Adzic. Also, Matt Wynne’s Example Mapping is a great way to break down the scope of a large item and identify the key questions you might want to discuss with examples.
Our way of working always encourages creativity and excellence in developing new digital solutions. Do you have the talent and the mindset? Join us.
