Product Backlog Refinement

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.”