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.
Alex, what about PBIs for the First Sprint? When do you refine the prioritized PBIs if there isn’t any phase before Sprint 1?
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/.
What and how exactly are we estimating during sprint refinement as opposed to the user story estimating done during sprint planning?
The estimation process during refinement is no different, it is an additional opportunity to estimate stories. For release planning, in particular, it is important that a significant portion of the stories, especially near the top of the backlog, be estimated at all times. Backlog refinement also allows the team to refine stories well in advance of sprint planning so that there is time to resolve any impediments that might exist to getting the story ready-ready prior to sprint planning.
Hello. I would like to share a question that has emerged on our team in recent days, and for which we have not found a clear recommendation.
The question is if you usually keep estimations for all PBIs or just for the ones of the next release? Should the team spend time working on estimates of each backlog item, so that the PO can think about prioritization and deadlines for all the project, even considering that estimates of the lower priority PBIs will be more imprecise? What is the good practice you have been used?
Thank you very much in advance.
This depends a bit on the needs of the team, the product owner and the organization, but the general approach that we recommend is that adding estimates to PBIs is done during refinement. PBIs near the top of the backlog should be refined to the degree that they are ready to be pulled on to the backlog next sprint. PBIs that are lower priority should be kept in a less refined state and should usually represent bigger chunks of work. These avoids wasted refinement as it allows us to adapt those stories based on what we learn as we implement the higher priority items. This larger, less refined stories can still be estimated and may be “epics”, that is stories that are too big to pull on to a single sprint. This estimation should be viewed as imprecise but tends to still be more accurate for release planning than waterfall techniques.
Backlog refinement and estimation is a request from the product owner to the team. A good product owner will structure the lower priority stories on the backlog in a way that allows for both flexibility and for the team to make the estimates that the product owner needs for his/her release planning without making that estimation process too lengthy or arduous.
If you’d like to dig deeper into this topic then I recommend checking out our release planning Scrumlab course here: https://www.scruminc.com/release-planning/.