Strategy Making -> Planning -> Estimation ->Architecture -> Design -> Risk Mitigation
Mike Cohn coined the word backlog grooming in 2005 and Kane Mar gave an official description in 2008. Finally, in 2011 it was popularly called as product backlog refinement (PBR). It is also called as product backlog grooming (PBG).
Effective completion of every iteration process is possible only when the backlogs are prioritized properly. These product backlogs are formed as user stories and the task is identified to be completed. The success formula of agile project management is just not because it is an iterative process but also it is a proactive approach. Every time the team does not wait for a retrospective meeting to be conducted for taking corrective actions. Then how do we handle this situation to save cost, time and energy? That is exactly what we are going to talk about in this blog.
PBR Vs PBG
Mike Cohn coined the word backlog grooming in 2005 and Kane Mar gave an official description in 2008. Finally, in 2011 it was popularly called as product backlog refinement.
It was basically called grooming as the activity involved is cleaning the backlog or trimming. However, since the word was felt to offer negative implication it was later named as backlog management or refinement.
Therefore, PBR and PBG are one and the same.
Before we get into all the details we would like to present you with a visual representation of PBR. Find below image that represents the objective of a PBR, who conducts, significance, duration, procedure, and best methods. 
What is Product Backlog Grooming (PBG) or Product Backlog Refinement (PBR)?
We will look in detail about product backlog refinement which will be mentioned as PBR throughout this blog. Product Backlog Refinement is a process in which the PO will review the backlog items to check if they are appropriate and prioritized to ensure a smooth delivery. It is a regular activity carried out by the team just before the sprint planning meeting (SPM). It is just not requirement processing discussion among the team and the PO but more than that as shown below.
The Objective of Backlog Refinement Session
The very purpose of the PBR session is to remove the user story that has become obsolete. Also, it aims at creating new stories based on the development of the project. To reassess the relative priority and assign estimates as well as correct the estimate on a need basis. It saves the SPM time as backlogs are maintained with the help of the PBR. The acceptance criteria are specified properly and verified by all team members. Finally, split the user stories to prioritize internally within them.
Product Backlog Grooming Agenda
• Create new item
• Remove obsolete items
• Create new priorities
• Check if the backlogs are ready to present for the SPM
• Impact of the items on the iteration
• Assign estimate
Who Participates in a PBR Session?
The product owner and the team members must participate in the PBR session. Scrum master is optional however the presence adds value to the backlog prioritization.
PBR Duration
PBR session time is based on the iteration frequency. For a 2-week sprint minimum of 1 hour, the Product Backlog Refinement duration is sufficient.
Product Backlog Grooming in Scrum Techniques
The Product Backlog Refinement goal. It is done by developing epics, conducting release planning, creating user stories, tasks, and estimating tasks.
Brainstorming session – This is the first step to start the PBR technique where the business, leads, PO, and architects discuss the items. Allow everyone to share ideas and then make a list of the plan.
Validate – Once the ideas are created it is required to validate and remove anything which is felt as overload and include items that are missed. Before implementing, validation will help to save time, efforts and cost.
Map the user story – The product owner and the team joins hands to map the user story. The rough idea is refined to the user tasks and this idea moves toward the implementation.
Backlog creation – Once the user story mapping is done its time to put them in the backlog. Now the entire Product Backlog Refinement process comes to an end and we can start with the iteration process. However, in parallel new PBR must be initiated to keep the work flowing smooth in every consecutive sprint.
Product Backlog Grooming Meeting Procedure
Even though there is no hard and fast rule, it is good to follow a process.
1. First, make sure the PO is present and aware of the customer needs.
2. The PO must get the team together and sit for a discussion. Together they analyze the backlog based on the previous iteration process or the customer need.
3. The development team takes input from the PO and suggests the technical value of the product before creating the user story.
4. PO will then amend the backlog in such a way that it reflects the result of the discussion among the team.
5. Later the PO will re-prioritize the backlog which has the highest priority product backlog item (PBI). There is a catch as there is just not one PBI but many levels that must be understood to prioritize the items.
Different levels of PBI
a. Epics are the high-level items broken into user stories.
b. User-centric items and the lower level is the user story.
c. Constraint stories namely the nonfunctional requirement items.
d. Research stories which will result in providing knowledge, choosing the right design, creating prototype thus helping to fulfill the goal of the spike,
e. Items that are technical which needs individual attention as the PO must realize the value of such items.
6. Now the team will provide an estimate for the new PBI.
7. Finally, the PO and the dev team refine the utmost priority PBI in the product backlog which includes the following steps
a. Include PBIs and get them ready for the upcoming sprint.
b. Decompose the epics and the large user story into smaller sized stories so that it fits the sprint. Make use of INVEST and create the best user stories.
INVEST will help to assess the quality of every user story because the acronym stands for
INVEST
• INDEPENDENT – User story to be individual and not connected to other stories so that assigning them will become easy
• NEGOTIABLE - The stories must be discussable
• VALUABLE – These stories should add value to the customers
• ESTIMABLE – They must be understandable and hence dividing them to task will be possible leading to correct estimation
• SMALL – Maximum 40 hours of time must be spent on any user story. This should be the size of a story.
• TESTABLE – The acceptance criteria must be testable which can be tested to find if they fulfill the customer need.
Why Product Backlog Grooming is Important?
Before answering the importance of the PBG you must know when it is done. It is done before the sprint begins. Also, there are three different scenarios, in which Product Backlog Grooming can be done.
• At the very beginning when there is no backlog at all. This is called the initial PBG.
• To generate a story at the time when the team discusses implementing the new feature.
• PBG as a continuous process that will keep a check on the healthy backlog.
Significance of PBR
• Make the product backlog fresh, and concise.
• Prioritize the product backlog.
• To ensure smooth delivery during every sprint.
• Identify the user and customer feedback proactively to prioritize the backlog and build the product.
• Keeping product up to date becomes possible with PRODUCT BACKLOG REFINEMENT and thus successful product development becomes easy.
• It enhances team efficiency as it reduces uncertainty.
• It refines the stories and hence makes it easy for estimation, implementation, and testing.
• Knowledge sharing happens among the team which gives clarity about the backlog and thus saves SPM time.
Top 5 Tips for Effective Agile Backlog Grooming
1. Start with a DoD
Definition of Done is the standard used to represent the list of conditions to be fulfilled by a backlog item. Yes, this is an exit criteria to be checked if each item will meet at every sprint completion. Items in DoD, in general, will successfully travel the following stages.
Development -> Testing -> User testing -> PO accepts -> Documentation completed
Use DoD as a checklist for the entire PBR process.
2. People and Discussion
Discussion must be conducted with the right people. Just the top management and business discussing with PO will not help. The entire team must take part and must be empowered to share views. The need for the item request must be well justified to create and assign the estimate.
3. Time-bound Facilitation
Even though the team must participate at the same time it must be time-bound. This means that not all will keep discussion without coming to an agreement. Also, just not one person must read out the agenda and conclude the session. Proper facilitation within a well-defined time must be done to prioritize the backlogs. Not necessarily the SM or the PO to be the facilitator, but one from the team also can do. This will give the team some confidence and ownership to work towards the sprint goal.
4. Do the Homework
It is important to take notes and plan before starting the PBR session. This will save time and be focused as well. Find the original use of the stories and then make the acceptance criteria so that it becomes a good starting point.
5. Estimation
First, estimate the item size and consider that as the test to align the team rightly. Every team member must provide inputs to the estimation. Use planning poker to effectively involve all the team members and estimate the size of each item based on the backlog items. Once the team agrees on the size then it becomes easy to align.
Conclusion
From the detailed discussion, we are sure that you will agree that PRODUCT BACKLOG REFINEMENT is one of the important scrum ceremonies. Thus there are 5 ceremonies in the place of standard 4 ceremonies. PBR is included too. Remember to make this session happen before SPM to prioritize the backlogs effectively.
Use small user stories and estimate the effort of each story. Rank the backlogs and then assign them based on their value. Finally, remember to make the team update the backlog items after the PBR meeting to get a shippable product that is ready for deployment in the market.
To get hands-on attend StarAgile Scrum Product Owner Certification, for more details call us at +91 – 95133 93880