Product Backlog Refinement (PBR) is one of the key ceremonies within the Scrum Framework in Agile Methodology. There are several myths about PBR. Some examples of these are,
- The Product Owner is responsible for PBR,
- PBR is not critical because the same stories will be discussed in planning,
- PBR is redundant for planning etc…
In this blog, however, I will try to break some of these myths and explain what PBR is; why we need it; when we conduct a PBR meeting; who should be a part of PBR, and what the desired outcome of PBR is.
What is a Product Backlog?
A product backlog is a prioritized list of work items for the development team that is derived from the product’s roadmap and requirements. The most important work items are shown at the top of the product backlog so the technology team knows what to deliver first. Most of these are represented in the backlog as user stories, as short, simple and clear descriptions of the desired functionality told from the perspective of the end user. An example of this would be, “As a product administrator, I can check the requests in the queue before approving/rejecting for a particular line of business.”
What is Product Backlog Refinement (PBR)?
Product Backlog Refinement is a scrum ceremony where the Product Owner (PO)and team (Designers, Architects, Frontend Developers, Backend Developers and Support groups like the security team) discuss the top priority backlog items thoroughly and keep the backlog clean and well organized.
Why do we need PBR?
Usually, the PO walks through the list of product backlog priority items with the technical team. This way the team gets an opportunity to ask the questions pertaining to the scope of stories which may be picked up in future planning sessions for upcoming sprints. Here, I have listed some questions I have received from the build team over the years.
- Does this story have any data persistence requirements?
- Where does this business information come from?
- What business rules apply in this scenario?
- When does a business user arrive at this screen?
- How do users access restricted items for this part of the application?
- What will the user need to see when he/she logs in to a particular module?
- What happens when you reject a request in the third step of the workflow?
- When a user deletes a record, what should happen?
- Is it a permanent delete or soft delete?
- Does this change have any impact on downstream/upstream applications?
- Does this change require a design modification?
- Are all the product technical components (frontend, backend and middleware etc…) aligned with the story/acceptance criteria?
The more questions asked by the technical team, the better the opportunity for a PO to analyze the story/feature for the product, and provide answers. If the right questions are not asked in PBR and deferred to the planning stage, the team might miss some priority backlog items. These discussions give confidence to the scrum team that the backlog can be considered for planning and is meeting the definition of ‘ready’. PBR results in efficient utilization of team capacity. The technical team gets an opportunity to clarify the requirement so the team can suggest improvements to the design and usability of the PO at the earliest. The team can then start creating relevant tasks and estimate stories as part of the PBR which reduces the list of topics in planning.
How Asking the Right Questions Help
When to Conduct the PBR?
The best time to conduct the PBR is in the middle or at the end of the current sprint. This is to make sure the backlog is ready in time for the next sprint. In the PBR meeting, whether conducted in the middle or at the end of the current sprint, the PO and the technical team have clear visibility of the ongoing sprint deliverables. You can push any setbacks, if any, to the next sprint as a priority backlog. Additionally, the PBR works as a gatekeeping mechanism to resolve issues that may crop up for upcoming planning sessions in subsequent sprints.
Who Should Participate in the PBR?
The whole team should ideally participate in the PBR. Alternatively, the key stakeholders – the technical team, the PO and Scrum Master can facilitate the PBR. If there is visibility into the backlog for Scrum Master prior to the PBR, the Scrum Master can invite the particular stream owners. This makes the PBR discussions more fruitful, leading to a better planning session.
Desired Outcome of the PBR
- A cleaner, more relevant and orderly backlog for Sprint Planning.
- The build team can estimate the stories and create relevant tasks for the team.
- The scrum teams can identify the external and internal dependencies ahead of planning.
- Allows POs to have a list of requirement gaps handy before the sprint planning meeting (if there are any).
- “Definition of Ready” meeting backlog with proper backlog summary, description, acceptance criteria, estimation and tasks.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
