In this article we will investigate how an effective Product Backlog refinement can be conducted in Scrum. The Scrum Guide defines it as “an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items”, but doesn’t give many details.
Why behind the refinement
Refinement reduces the variability of Product Backlog Items before they enter the Sprint which is very important. The Law of Variability Placement [HS08] reveals that the worst place for variability (in terms of negative cycle-time impact) is at the front end of a multi-stage system with queues. Sprint is a multi-stage system. When Product Backlog Items become “ready”, a Development Team has fewer “surprises” during a Sprint, and the chances to reach the Sprint Goal increase.
Developers communicate directly with customers
Often middlemen are placed between developers and the customers. These middlemen impede direct communication and are a source of multiple types of waste:
-
transitional artifacts (BRD, large batches of specifications, etc.)
-
handoffs, the distortion and loss of information
-
low speed of decision making
-
information scatter
-
developers having little empathy to the customers and/or users
-
lack of business domain knowledge.
Stakeholders (internal, clients, users) should be able to communicate directly with the Development Team. Interviewing users and clarifying the requirements is an essential job of the Development Team.
When many teams are working on the same product, then the Product Owner has little time for clarifying Product Backlog Items. She is too busy and may delegate this activity to the Development Teams.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product...
...The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable (Scrum Guide).
Some teams send representatives to Product Backlog Refinement (PBR). I do not recommend it. It causes handoffs and information scatter. Those could be eliminated when the whole team participates.
Business analysis is a team responsibility
Another pattern I observe is a business analyst being a part of the Development Team but focusing exclusively on business analysis. Formally he is the part of the team, but acts as a middleman between customers/users and the rest of the team. He locally optimizes himself creating transitional artifacts and handing them over. In this scenario BA is usually separated from the team and works one/two Sprints ahead. Remember that Scrum is the style of organizing work differently. The whole team is moving the ball (Product Backlog Item). Business analysis is a common, regular activity that everyone in a Development Team can be engaged in.
An example of the effective refinement
The context is a large product group (≅30 people) working on one product. Thus, one Product Backlog and one Product Owner. Two Development Teams were invited to the event along with the internal stakeholders. We wanted the developers to clarify the requirements directly with them.
The goal and working agreements. (5 min)
Any meeting starts with the definition of its goal, desired outcomes and working agreements. In our case, the goal was as follows: “Split a large feature” the desired results “ordered minimum set of smaller features are ordered”. The timebox was two hours and also we agreed on taking a break in the middle.
High-level clarification (10 mins)
We spent 10 minutes in open discussion, clarifying the giant feature in the following format:
-
Who: customer segment it relates to
-
What: high-level scope
-
Why: business and customer value
Forming small groups (5 mins)
It is most effective to work in small groups of no more than five people. Each group should have at least one stakeholder or business expert and include representatives of various teams. We managed to form three groups.
First round: splitting (20 mins)
Since the main aim was to split a large feature, we gave everyone splitting patterns and asked to come up with a splitting tree. At the top of the tree was the initial requirement that needed splitting. When suitable pattern for splitting was found group moved to the next level etc. (see the diagram)
Second round: rotation (5 mins)
We asked to leave one representative at the station and move clockwise to another station. The goal was to investigate what other teams were doing and receive feedback. One of the groups might have come upon an interesting option for splitting and it was important for everyone to find it out.
Break (10 mins)
Working in a focused manner for more than an hour is hard work. Even if the participants say they are not tired and are ready to continue, we insist on taking a short break. Tea, coffee, and glucose (sweets and biscuits) are very useful. Nonetheless, it is a good sign when some people remain on their stations and continue working. That means they are fully engaged.
Third round: complete splitting (20 mins)
After the break, we game another 20 mins to complete splitting. The aim of splitting is obtain small Product Backlog Items that can be “Done” in a Sprint (“ready”). This is one of the splitting options that one of the groups came up with:
Fourth round: merging (20 mins)
The groups presented their options for splitting in an open discussion. It is interesting that they came to up with similar conclusions. The minimum feature set turned out to be surprisingly small. The main insight of the refinement was that the major business value could be achieved with relatively little effort. Everyone agreed that this format for conducting refinement was highly effective. When developers communicate directly with business stakeholders in small groups armed with stickers, markers and paper, the results are astonishing.
Main Ideas
-
Developers should communicate directly with the stakeholders.
-
The whole Development Team participates in the refinement.
-
The Development Team as a whole is responsible for business analysis.
-
Product Owner is more focused on ordering while the Development Team on clarifying items.
-
Refinement can be conducted effectively in small groups using diverge and merge cycles.