Do you have a Product Backlog refinement meeting?

Last updated by Matt Wicks [SSW] 4 days ago.See history

When a Scrum Team meets for Sprint Planning, they want to plan out the next week's work so they can get cracking on improving the product.

The Problem - Sparse PBIs

The team often runs into a roadblock when they find that the Product Backlog Items (PBIs) are lacking in basic details.

This problem leads to 1 of 2 outcomes:

  • Poorly defined PBIs being added to the Sprint causing problems with shaky estimates and later down the track when developers are unclear about these PBI details and how to implement them
  • A lengthy Sprint Planning meeting (with only a few people engaged) while refining these PBIs

The Solution - Product Backlog refinement meetings

You can avoid these scenarios by having well defined PBIs written in advance so the Sprint Planning session is simply a tick and flick.

The Scrum Guide mentions the process of refining the Product Backlog as the core way to avoid these issues. Product refinement involves breaking PBIs into smaller and more manageable units of work with precisely defined requirements. This process ensures that work involved with each PBI is well defined and measurable that the outcomes of completing them are measurable. A Product Backlog Refinement meeting is a great way to ensure the Product Backlog is regularly refined. In this meeting, the Tech Lead and another developer refine all the PBIs.

This process involves refining the PBIs in the backlog and adding a "Ready" tag or status when the PBI has met the Definition of Ready.

To ensure the Product Backlog Refinement meeting runs. Setup a recurring meeting with the following agenda:

pbi marked as done
Figure: PBI should be marked as “Ready” before pulling it into the Sprint

Sometimes, we may encounter urgent new requirements and priority changes that need to be pulled into the Sprint immediately. You can handle this by following the unexpected PBI's rule.

✅ Benefits of Product Backlog Refinement

  • Efficient Sprint Planning - With most PBIs already refined, the Sprint Planning meeting becomes more efficient
  • Less time wastage - Only the Tech Lead and another developer are required for most of refinement, so other people's time can be utilised elsewhere instead of wasted waiting around
  • Risk mitigation - If the Product Owner or important stakeholders have to go on leave there is some extra buffer in the Product Backlog
  • Engaged developers - Developers are more likely to stay engaged when meetings are shorter and more focused
  • Well-defined PBIs - PBIs are well-defined before being added to the Sprint
We open source. Powered by GitHub