Product Backlog Refinement (Grooming)
There is a motto in Scrum as “Scrum is not a methodology, process or a technique for building products. Scrum is a framework describes roles and rules upon principles that help and facilitate people in a low-prescriptive way”. While Ken Schwaber and Jeff Sutherland prepare the Scrum Guide, they define the rule set of this game and indicate that procedures and processes should be applied according to this skeleton. Therefore, Scrum is known with its simplicity to understand but hard to execute. I predefine the Product Backlog Refinement, according to my experiences which mentioned in Scrum Guide with only one paragraph.
What is Product Backlog Refinement?
Product Backlog Refinement is a process that the team reviews the PBIs and details them to ensure each team member understands the items clearly. This process is not only detailing the User Stories, but also making assumption about the tasks and ordering them. While detailing section based on the question “what” that is asked to customer by Product Owner; ordering section is based on the “why” question. Both questions are guide for Product Owner about creating Product Backlog Items as Theme, User Story or Epic. (https://www.linkedin.com/pulse/theme-user-story-epic-ali-saracoglu-mba-psm-pspo-itil?trk=pulse_spock-articles)
Do not forget that, making the Product Backlog Refinement comprehensively will be helpful for Sprint Planning Meeting.
When the Product Backlog Refinement needs to be conducted?
Scrum Guide refers that the Scrum Team decides how and when the Product Backlog Refinement is done. What is more, Product Backlog Refinement is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.
As a best practice, Product Backlog Refinement starts with a meeting that is done in the middle of the previous Sprint and continues until the Sprint Planning of the Sprint.
Who participates the Product Backlog Refinement?
Because Product Backlog Refinement is an ongoing process in the act of adding details, estimating, and ordering items in the Product Backlog; all the Scrum Team should participate the meeting to understand the requirements with details and with goal of doing them all. In addition to the team, if necessary, related stakeholders’ attendance might be helpful.
Product Backlog Refinement is an agreement meeting between Product Owner and the Scrum Team. Therefore, this meeting is conducted by Product Owner who knows the stakeholder’s requirements from the firsthand.
What should be considered during Product Backlog Refinement?
There might be digress from the issue or missing points in the requirements which may cause making wrong estimation.
Even if there is not a definite time box of the Product Backlog Refinement in Scrum Guide; you can define a time for grooming an item. With the help of it, duration of the Backlog Refinement can be assumed. In that case, some item’s grooming might not be finished. This case caused because the requirement of the User Story is not certain for even Product Owner or this item should be considered as an Epic.
Scrum Guide mentions that Product Backlog Refinement consumes no more than 10% of the capacity of the Development Team. Therefore, it may be said that, for the two weeks long sprint, we do not spend more than 1 day for the Product Backlog Refinement.
In real life, while a sprint is going on, necessity of focusing on the next sprint is the most challenging issue for Product Backlog Refinement. However, if this case is managed in the right way, in consideration of the coming issue, current sprint’s items can be formed before they closed. In addition to that, starting the Sprint Planning with knowing the PBIs details, helps the Team think about tasks. In first few Refinement meeting, it may be perceived as losing focus of current sprint; sooner or later, participants will realize that this study ease the Sprint Planning period and get motivated.
What are the outputs of Product Backlog Refinement?
As an output of the Product Backlog Refinement, Product Backlog Items are upgraded and User Stories are created. What is more, Definition of Done for the PBIs are updated. Creating Definition of Done for items with “Given-When-Then Statement” is one of the most preferred methods because it provides transparency and enquiry. (https://www.linkedin.com/pulse/given-when-ali-saracoglu-mba-psm-pspo-itil?trk=prof-post). Architecture of the work packages, workflow diagrams and user interface mockups are updated as an output of Product Backlog Refinement. All the test scenarios (especially unit and integration tests) are started to be created.
In conclusion, there is a truth that Product Backlog Refinement provides speed and productivity. With the help of these meetings, Scrum Team aims to decrease the risk factors (Scrum Guide- Scrum Theory, “Scrum employs an iterative, incremental approach to optimize predictability and control risk”). I compile this article with my experience and knowhow like all my other previous articles. Having said that, Scrum only provides a framework, therefore if you have better experiences or better best practices, I will be more then glad to hear about them.