Agile DevOps Part 5 – What is Product Backlog Refinement in Agile Development?

Cloud

April 28, 2021

Welcome back to the world of agile DevOps!! In this fifth blog of the series, we will have a detailed discussion on product backlog refinement in Scrum for agile development and why it is vital when following agile Scrum.

In agile Scrum, the product backlog contains all the requirements that a team needs to deliver. It contains all the epics, features, stories, and tasks that need to be delivered by the team.

If the product backlog is not detailed enough, always emerging, not estimated and prioritized, then this can derail the entire project. It is the responsibility of the product owner to maintain the product backlog in a healthy state with the help of the entire team by conducting grooming sessions.

What is Product Backlog Refinement?

Product backlog refinement, also known as product backlog grooming, is one of the important events of agile scrum. The prime goal of this event is to keep product backlog items ready and move from uncertainty to certainty. Though this event has not been a formal ceremony in scrum guide, we recommend having this as a ceremony for creating a healthy product backlog. Following product backlog refinement best practices is vital because a healthy product backlog is the base for agile development and the dev team has to deliver scope within the product backlog. It is very essential that grooming is effectively used by the entire scrum team to optimize its advantages.

Understanding Different Aspects of Agile Product Backlog Refinement

As mentioned earlier, product backlog refinement is considered as an important event in agile Scrum execution of projects as it helps to maintain a healthy product backlog and ensures that backlog items are handled systematically and strategically. To get a better understanding of product backlog refinement in Scrum, let’s understand its different aspects and how they help in better product management.

Aspects	Details
Goal	To keep product backlog items ready for future sprints, thus moving items from uncertainty to certainty
When does the process start?	It’s a continuous process between and during the sprints
Who is responsible for the process?	The scrum team is required but it is the responsibility of the product owner
Process inputs	Release strategy, priority as per business value, existing product backlog and, dependency/ risks
Process duration	At least 1 hour per week (depending upon the team’s availability) is recommended
Process activities	Story Elaboration – Ensure user stories and tasks are detailed and have acceptance criteria and designs expected to build a story Identify a spike in case there are technical unknowns. This task should be treated as a child of the main story/task. Order items as per priority Add, remove, modify, split and, merge existing product backlog items to achieve the release scope/ goal Identify and discuss risks, dependencies and, other uncertain items in the acceptance criteria Look deeper into the backlog to do long-range technical planning Size the backlog items (add story point using planning poker), try to get stories to 5 points or less than half of sprint Improve user stories that are poorly written or not precisely sized (story point estimate) items
Process output	Product backlog items are 100% ready for future sprints
Roles and responsibilities	Scrum master – Facilitate discussion Product owner – Provide clarity for each product backlog item. Update product backlog. Give 100% involvement and involve the team. Development team – Understand the needs of product owner, acceptance criteria and, seek clarification. Help to order the product backlog.
Exit criteria	List of epics, stories and, tasks organized and prioritized for future sprints and ready for sprint planning There are backlog items in n+1 sprint and n+2 sprint having story points on them. Team should start with having story points on n+1 sprint and aim to improve for having story points on the n+2 sprint over a period.
Tools & templates required	Story/ task issue type from JIRA Product backlog in JIRA Checklist can be created from DOR by the dev team to verify readiness of product backlog items
JIRA impact on the process	Feature backlog for N+1 and N+2 sprint Blockers are updated Risks are updated Future sprint numbers are assigned to ready stories and tasks as per planning Fix version is updated Stories are sized Stories are as per approval by PO (i.e. JIRA status can be set as ‘ready for development’).
Metrics collected during the process	Backlog health – If N+1 worth of story points are groomed then, backlog health is Amber and, for N+2 or more worth of stories, backlog health is Green. Else, it is Red.

The above aspects help the team to move the uncertain items to certainty, which means the team is clear on what it must deliver in what order and can better prepare itself for the upcoming sprints.

Conclusion

An unhealthy product backlog results in an unhealthy sprint backlog and the entire purpose of having the backlog in place is defeated. A healthy backlog along with maximum teamwork is required for the success of an agile Scrum project. Once a team knows what is to be delivered, in what order, and in how much time, it becomes easy to plan for Sprints and get the work done.

Backlog grooming ensures that backlog always remains in a healthy state and the DEEP criteria (Detailed, Estimated, Emergent, and Prioritized) is met. This plays a key role in successful agile development along with strategic product management.

About the Author

Suhas Mali

Suhas Hanumantrao Mali, Sr. Consultant – PMP, CSM, CSPO, SAFe Agilist, ITIL V4 Foundation, MS Azure Fundamentals – has over 20 years of IT experience out of which majority of experience is in Project Management, Pre Sales Solution Architect and Agile Coaching. Author has coached 1000+ Consultants in Hexaware and at Client locations, experienced in leading Enterprise Agile Transformations and Technology Migrations, experienced in coaching Business Teams, Product Owners, Scrum Masters and Development teams in Lean and Agile Frameworks.