Product Backlog Refinement: Make the Most of It

Product Backlog Refinement or grooming is a vital technique to successfully deliver a valuable product to customers and users. Actually, it includes far more than requirements processing, but also strategy, planning, estimation, architecture and design, and risk mitigation. Let’s have a close look at what a Product Backlog Refinement is and how to succeed with this technique.

What Is a Product Backlog?

The BABOK Guide states:

"The backlog is used to record, track, and prioritize remaining work items."

Also:

"In a managed backlog, the items at the top have the highest business value and the highest priority. These are normally the next items to be selected to be worked on."

So, the Product Backlog is a collection of work items which is valuable from the Product Owner’s perspective and which needs to be done to complete the project. Product Backlog items (PBIs) may have different nature and level of detail:

• Epics – high-level items, which need to be broken down into User Stories.
• User Stories – user-centric low-level items.
• Non-functional requirement items like Constraint Stories.
• Spikes – research stories that will result in learning, choosing proper architecture or design, creating prototypes, etc. to fulfill the goal of the Spike, based on which proper User Stories will be created later.
• Technical items  (like refactoring, configuring Jenkins, etc.) – these items should be separately discussed with the Product Owner for him to see the value of them.
• Bugs, etc.

Who Is Responsible for a Product Backlog?

The Product Owner holds responsibility for the Product Backlog. At the same time to efficiently manage the Product Backlog this activity should be done collaboratively with the Development Team.

What Is a Product Backlog Refinement and Why Is it so Important?

Agile Extension to the BABOK Guide states:

"Backlog Refinement is a continuous technique used to prepare product backlog items for an agile team to deliver."

This technique plays an important role in product development as it allows to:

• Make the Product Backlog reflect feedbacks from users and customers from the last Sprint – to know that we are building the right product which is really valuable for users and customers.
• Leverage our learning about the product and best ways of its implementation.
• Keep the Product Backlog fresh, concise and in order.
• Keep the Product Backlog properly prioritized.
• Make sure that high-priority PBIs are ready for the Sprint Planning – they should be sized properly to fit into the Sprint and detailed enough for the Development Team to do the required work.

When Should Product Backlog Refinement Be Done?

Generally, the Product Owner on a continuous basis adds new PBIs, adds details such as the acceptance criteria to the existent PBIs, prioritize PBIs, etc. Nevertheless, it is highly important to have a separate Product Backlog refinement meeting each Sprint where all Scrum participants (the Development Team, the Scrum Master, and the Product Owner) can gather, review and do proper work on the Product Backlog.

The best time for such meeting would be a few days prior to the next Sprint planning meeting. This way the Development Team will have more time to understand new User Stories, do some analysis of them if needed and better prepare for the Sprint Planning meeting. The Product Owner, in his turn, can better understand the Development Team’s view and properly write/amend acceptance criteria for the highest priority User Stories, which are the main candidates for implementation in the next Sprint.

The Product Owner may write acceptance criteria collaboratively with the Development Team representative, for example, a tester.

How to Hold a Product Backlog Refinement Meeting Effectively?

• The Product Backlog Refinement meeting should be time-boxed – usually around 2-3 hours for a two-week Sprint. Generally, the Scrum Guide suggests that Refinement should consume no more than 10% of the capacity of the Development Team.
• The Product Backlog Refinement meeting should be facilitated by the Scrum Master to keep on track.
• All Scrum participants – the Development Team, the Scrum Master and the Product Owner should attend the meeting.
• Everyone should have access to the Product Backlog and see what is going on.

What Is the Procedure to Follow during the Product Backlog Refinement Meeting?

There is no strict procedure to follow, but to leverage the Product Backlog Refinement meeting the most, it would be good to go through the following steps:

1. The Product Owner presents the plan for the meeting.

2. The Product Owner presents changes done by him in the Product Backlog since the last Product Backlog Refinement meeting (if there are any) and explains why they are needed.

3. The Product Owner presents the feedback and data collected from users and customers after the last Sprint delivery and discusses with the Development Team what should be changed/added to the Product Backlog based on this information.

4. The Development Team suggests PBIs which are of technical or quality value for the product (for example, configuration of a new CI tool which will greatly improve the product development process and make it quicker).

5. The Product Owner amends the Product Backlog to reflect the results of the discussions.

6. The Product Owner re-prioritizes the Product Backlog to have the highest priority PBIs at the top of the Product Backlog.

7. The Development Team may provide estimates for new/amended PBIs.

8. The Product Owner together with the Development Team refine the highest priority PBIs in the Product Backlog:

- Decompose Epics and big User Stories into User Stories sized properly to fit into the Sprint.  (Use the INVEST criteria described in here to create good User Stories)

- Add/amend details to PBIs to make them ready to be worked on in the next Sprint.

Remember, all PBIs which are candidates to be worked on in the next Sprint should be detailed enough (have properly written acceptance criteria), small enough (to fit into the Sprint) and estimated! Use Definition of Ready criteria to produce good PBIs for your next Sprint.