Product Backlog Refinement

Because requirements in Scrum are only loosely defined, they need to revisited and clearly defined before they come into the Sprint. This is done during the current sprint in a ceremony called Product Backlog Refinement.

Estimated time for this course: 5 minutes
Audience: Beginner
Suggested Prerequisites: Scrum Framework, Definition of Ready, Definition of Done

Upon completion you will:

Have a basic understanding of Product Backlog Refinement
Know how much time to dedicate to refinement
Know how to break large stories into small
Understand the need for the a Definition of Done
Understand the need for the a Definition of Read

Product Backlog Refinement Overview:

A crucial guideline in Scrum is that five to ten percent of every Sprint must be dedicated to Backlog Refinement. As the slides illustrate, this includes:

detailed requirements analysis
splitting large items into smaller ones (epics to User Stories)
estimation of new items
re-estimation of existing items

Product Backlog Refinement is not for PBIs selected for the current Sprint; it is for items in future Sprints. A good practice is to have at least two Sprints worth of work ready to go in the Product Backlog. Sprint Planning becomes relatively simple because the Product Owner and Scrum Team start the planning with a clear, well analyzed and carefully Estimated set of stories. If refining the Backlog is not being done (or not being done well) Sprint Planning will involve a significant amount of questions, discovery and or confusion.

There are two critical parts of stories: getting them “Ready” and then getting them “Done” -- according to the agreed upon definitions of “Ready” and “Done.” The refinement meeting is when the Registered Product Owner (RPO) makes sure that stories are “Ready” so the team can immediately execute them when they are put into a current Sprint and get them to “Done.”