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 Scrum Inc Product Owner 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.”
