Working with requirements is crucial for Agile software development, so teams often use Product Backlog Refinement to ensure that all parties understand what is expected of them.
According to the Scrum Guide, “Product Backlog refinement is the act of adding detail such as a description, order, and size to items in the Product Backlog.”
But the Scrum Guide does not give a detailed description of how exactly to undertake this task. It provides flexibility and allows teams to choose the frequency of, approach to, and techniques used in Product Backlog Refinement. The customizable nature of Scrum meetings is important, but you should still keep in mind the key elements of Product Backlog Refinement.
In this article, we’ll share a few ideas that will help Scrum teams with refinement and involve Developers in requirements development.
What is Product Backlog Refinement and What Should it Look Like for my Team?
Product Backlog Refinement can be done during Sprint planning, although we at Exadel don’t recommend that, especially for new teams. For mature teams, where the product is well known and the team is highly experienced, this option can work, but for a new team or product, we suggest going with recurring Product Backlog Refinement meetings.
The team can adjust the length and frequency of the meeting, or even cancel them altogether, depending on what’s necessary at the moment. The best way to determine how often your team needs Product Backlog Refinements and how long the meetings should last is by gaining experience and making mistakes.
If Product Backlog refinement is not being done (or not being done well), Sprint Planning may involve more questions, discovery, and/or confusion.
So to help your team with effective planning, start with a well-refined Product Backlog, make sure the backlog is “Ready” before the Planning, and let the team concentrate on the Sprint Goal during the planning meeting itself.
Preparing for Product Backlog Refinement: Define what Backlog Items Should be Considered “Ready” or “Done”
During the Product Backlog Refinement meeting, the Product Owner makes sure that the product backlog items are “Ready” so that the team can immediately execute them when they are put into a current Sprint and get them to “Done.” By “Ready” and “Done,” we mean the Definition of Ready and the Definition of Done.
The Definition of Ready (usually abbreviated as DoR) represents all the things that a product backlog item must meet in order to be “Ready” to take into the Sprint. The DoR can serve as a checklist for the team to guide their Product Backlog Refinement process.
The Definition of Done (usually abbreviated as DoD) is a quality standard that represents all the things that a product backlog item must meet to be considered “Done” by the Scrum Team. The Definition of Done is also considered to be the exit criteria that each item needs to meet at the end of the Sprint.
Running an Effective Product Backlog Refinement Meeting
1. Shift & Share methodology:
Shift & Share gets rid of long large-group presentations and replaces them with several concise explanations made simultaneously to multiple small groups.
- The Product Owner assigns, for example, one person who will be in charge of a station. The Product Owner shares the concept of what they want to see and why.
- The Product Owner themselves occupies another station.
- We split the team into two groups and send each group to different stations.
- The host of the station explains a concept and main idea of the product backlog item, the team discusses, asks questions, and immediately adds necessary details to the product backlog item: description, acceptance criteria, mockups, assessment, etc.
- After 20 minutes, the groups change stations and repeat the process.
- The entire team comes back together, and the Product Owner looks at the brainstormed ideas and answers any remaining questions. If sizing isn’t already complete, it should be done at this point.
Please note, exact timing may vary from team to team. Try different options and choose what works best for your team.
2. The minimal specification technique
Minimal specification (Min Specs) specifies Only the Absolute “Must Dos” and “Must Not Dos” for Achieving a Purpose.
- The Product Owner asks developers to create a list of all must-do and must-not-do requirements (Max Specs). The goal is to include as many elements as possible. This means you should:
- Have every team member prepare their own list of requirements in one minute.
- Organize people in small groups (2-4) and ask them to combine their lists in 6 minutes. Together they refine their lists, combine them into one document, and add new items. The resulting document is a Max Spec list.
- Each group checks every item on its Max Spec list to see if it correlates with the purpose. If the purpose can be achieved without the item, that item is deleted from the list. This round should take around 15 minutes.
- If it’s necessary, hold a second 15-minute round.
- In 15 minutes, make a short list of requirements while comparing the specs from small groups.
The output of this activity is several sentences with maximum value and minimum work. This is Min Specs.
Again, exact timing may vary from team to team. Try different options and choose what works best for your team.
If you are interested in this technique, you can read more here.
3. Use the “celebrity interview” technique
Need help with
Join our team!
This technique will help reconnect the leaders, business representatives, and subject matter experts with people who are much closer to the existing product’s challenge at hand.
The Product Owner invites a “celebrity” (an end user, subject matter expert, Product Owner, etc.) to the backlog refinement. Someone on the team (a Developer or Scrum Master) should be chosen as an “interviewer.” Agree within the team about who will document questions and answers.
Follow these steps to implementing the “celebrity interview” technique:
- The Product Owner introduces the topic or product backlog item to be discussed.
- The Interviewer asks questions that the audience would be expected to ask, like a general description of the product backlog item, expectations, limitations, etc.
- At the same time, participants generate additional questions and send them to the interviewer.
- The interviewer sifts through the questions, looking for patterns and then poses them to the celebrity.
- If the interviewer is not comfortable with questions, they may turn to the audience, at which point participants can take turns asking the celebrity their questions directly .
- Closing comments, thank the celebrity.
The team will communicate and collaborate during requirements clarification, which encourages developers to be involved in the process, so Product Backlog Refinement won’t just be another meeting where a Product Owner presents a list of requirements.