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 in 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 Ready
- Qualify for Scrum Alliance SEUs and PMI PDUs. See FAQ for details
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 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.”
Download and View Class Slides
Explore ScrumLab Prime
Are you ready to advance your Scrum knowledge? Prime members enjoy unrestricted access to all our webinars and advanced Scrum topics.
Clearly defining the requirements should occur during Sprint Planning, not the backlog refinement. Backlog refinement is more geared towards setting priorities, estimating effort, breaking down features, and making sure the user story is clear. If you acquire all of your requirements and design before Sprint planning, then you are doing Waterfall. Always consult the original scrum guide for factual definitions of Scrum.
The speaker in the video shown is actually Jeff Sutherland, the co-author of the original Scrum Guide (see hee: http://www.scrumguides.org/), which states, “Product Backlog refinement is the act of adding detail, estimates, and order to items in the
Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.”
Requirements and clear concrete definitions of done are absolutely done during backlog refinement and fall into the “detail” category in the description above, which on a 1-week sprint cadence would often happen ~2 times per sprint and within a day or two of sprint planning. Stories should be mostly ready-ready heading into sprint planning, doing so is definitely not waterfall! Of course if PBIs need to be adjusted at sprint planning based on the sprint review or the events of the last day or two, that is fine, but a team should not go into sprint planning with a backlog full of stories with no DoDs or requirements.
At around 0:50 in the video Jeff Sutherland says:
“They [the team] will pull from the product backlog. That’s one of the things that’s very different from scrum.”
Perhaps he meant “different _in_ scrum” or “different from (something else)”?
He definitely misspoke here, good catch! He meant “different in Scrum” (as compared to waterfall).
In general: Can a refined PBI be considered as being Ready?
Assuming that part of refinement is making sure that the item is “Ready Ready”, ie that it is immediately actionable, of the appropriate size, and prioritized by business value, then yes. I recommend checking out the “Definition of Ready” video which is here: https://www.scruminc.com/definition-of-ready/.