Product Owner’s Checklist for Product Backlog Refinement
As a Product Owner (PO), your responsibility is to split the product vision into the product backlog items and have it ready for the development team to implement it. The tough job isn’t it?
Product Backlog Refinement or PBR or Refinement or Grooming is the process of clarifying and estimating the backlog items. The estimated backlog is the output of the PBR.
How do we do refinement?
The refinement of a product backlog is iterative, progressive, and constant.
- The first step is to define the product vision and understand the stakeholders
- The second step is to identify the significant features of the product
- The third step is to determine the detailed user stories
You will perform these three steps iteratively as follows:
- The product vision you refine its maximum ones or twice a year
- The significant features you groom them every program increment or every 2–3 months and
- The user stories you look at them every sprint
I strongly recommend to all the Product Owners I work with to define a fixed time and frequency of the PBRs at the beginning and keep it constant. The Product Bnbacklog Refinement is a routine. I recommend 1.5h a week every week. The books recommend about 1–2h per sprint. But out of many years of experience, I can tell you the winning formula for me: 1.5h a week and use the time to refine features, user stories, vision, anything relates to building your product roadmap and predictability.
Depending on where you are in your schedule in each Refinement meeting, you’ll approach a different subject. Let’s say for example, that you are using Scaled Agile Framework, here is how you are going to split your PBR content:
- in the first two sprints of the Program Increment (PI), you will refine the user stories of the next two iterations. It means that by Sprint 2 you have refined the whole backlog of the Program Increment
- in the future two sprints of the PI you as PO, with the scrum team, you’ll groom the features you intend to implement in the next PI. They will help you as a Product Owner to define the Product Roadmap
- in the Innovation and Planning sprint you’ll refine the user stories of the top features because they’ll be implemented first in the next PI. You will prepare with your team to have the first sprint(s) ready to start after the Program Implement Planning Meeting.
I have prepared a list of 14 points checklist the Product Owners should prepare for the Product Backlog Refinement:
- Prepare the context of the product: vision, stakeholders’ understanding, expectations, strategy, product milestones, investor’s expectations, product benefits, business model.
- Create the product roadmap, show how the features and the user stories fit into the product roadmap
- Work with the scrum master to timebox the meeting
- Define the goal of the meeting — what you want to achieve at the end of the meeting
- Invite Subject Matter Experts (SME) for specific discussions.
- Invite representatives from other teams for a cross-team PBR
- Order the user stories and features based on the highest business value always on top.
- Prepare designs, data, and examples for each user story that needs it.
- Write the user stories before the refinement meeting: description, acceptance criteria
- Write the features before the refinement meeting: description, benefit hypothesis, acceptance criteria, business value
- Assign the user stories to a release.
- Share the release schedule with the team and the impact of the next release
- Understand team velocity — it is a good indication of how many user stories the Product Owner needs to prepare for the PBR. You want to have the right amount of user stories. The right amount is two sprints in advance, and features estimated for the next program increment. Having the user stories or the features refined for longer than one month for the user stories and two months for the features may lead to a waste of effort. Because the team will not remember all the details, priorities change, more information arrives. As a Product Owner is vital to do Just the Right Amount of Work.
- Make sure the user stories are INVEST:
- I(independent) — the user stories can be done in any order,
- N(negotiable)- together with the team, you can negotiate the scope.
- V(valuable) = each user story implemented must bring customer value
- E(estimable)- the development team can estimate the user stories,
- S(small) — teams do smaller user stories faster, but they should be big enough to don’t require more administration work than the implementation
- T(testable)-anyone with context knowledge can perform unit and acceptance testing.
What is your Product Backlog Refinement checklist as a Product Owner?
You might be interested in:
