What is Product Backlog Refinement in Scrum?
IT Tips & Insights: A Softensity Product Manager walks you through the basics of product backlog refinement.
By Jorge Garay, Product Manager
Although product backlog refinement in Agile Scrum is not a formal event, it is something that all teams do as part of their job in getting a product implemented. Let’s start with some definitions as they appear in the Scrum Guide and in The Professional Product Owner book by Don McGreal and Ralph Jocham. This is an excellent book for people with product ownership accountabilities and for Scrum professionals in general.
What is Product Backlog Refinement?
The 2020 Scrum Guide contains a concise yet very clear definition: Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Interestingly, the previous version of the Scrum Guide from 2017 is more extensive, providing more details on what it is, who does it and how it is done: 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. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
From the The Professional Product Owner book by Don McGreal and Ralph Jocham we get the core idea: Refinement is about getting your Product Backlog Ready for upcoming Sprints.
The word ready is the key here.
Let’s suppose we have a product and its product backlog with tens or perhaps hundreds of items to be implemented into our product. Each item may start as just a title (e.g.: “Sign Up Form”) and needs to be refined. This is adding detail about what the customer or end user expects as part of this particular feature. It includes scope of functionality, negative scenarios, rules etc. There are a number of things to consider, such as how much refinement is required, the size of the resulting product backlog items, and when to do refinement.
The Basics of Product Backlog Refinement
As a precondition you should have a good definition of ready. This is the standard with which the product backlog item is measured against. In other words, a set of criteria that a user story must meet in order for it to be considered ready for implementation/development. If the team doesn’t have a definition of ready for the project they can grab one from their organization and adapt it or create one from scratch. Following the INVEST acronym will help in creating and or adapting an acceptable definition of ready: independent, negotiable, valuable, estimable, small and testable.
You as the product owner must have a meeting with stakeholders and come up with a list of requirements for the product in the form of short sentences. For example “Customer Sign Up,” “Account View,” “Balance Report,” etc. Part of the conversation is understanding the details and the relative order of importance to each other and to the existing product backlog items.
Next step is to add all this information to the product backlog documenting system (Jira, MS Azure Board, or even post-its on the wall) with the necessary details gathered in the meeting. Every item will end up with a title, description, acceptance criteria and a position (order) within the backlog.
What comes after that is one or more review sessions with the Scrum team and the stakeholders. This is the refinement, per se. Anyone with basic knowledge of the business process/area should easily understand the user story and comprehend its purpose. Is it clear? Can it be done in one sprint? Is it testable? Is there value by implementing it? Is it aligned with the product goals? Is its priority correct?
When all the answers are Yes and the INVEST guidelines are satisfied we can consider the refinement complete and the item ready.
To what extent does the product owner need to refine each item?
Considering that the development team needs to clearly understand what to implement, it is crucial to involve them in the refinement process. Their maturity and domain knowledge (in relationship to the project itself, the customers, the product, the industry, etc.) will provide the required level of detail and how much refinement needs to be done.
A positive effect of the team’s involvement is that this leads to more ownership and engagement with the product and its backlog. Going back to the ready concept, an item gets refined until the team considers it is ready to be done in a sprint. The word done is stressed here too because it is another important concept in Scrum that deserves a separate discussion. But, let’s continue with the refinement.
Scope
To save time and effort only the items to be implemented in the next few sprints are subject to this refinement process. The main reasons are two:
- The refinement is an activity that demands effort from the entire team, so if the developers are doing refinement they are not working on the sprint increment. So we need to find the optimal balance for the team to work on deliverables and at the same time being comfortable refining items for the next sprints.
- The cone of uncertainty: The further we go into the future, the less we are certain of the product and its features. This translates directly into the product backlog. An item in the bottom of the backlog would be implemented in a long time, and therefore there is a high probability of it being changed or even discarded. So it might not make sense to work on something that won’t get into the final product.
Size of Items
Another factor to take into consideration is size. If an item “grows” during refinement — meaning as part of the discovery process with the team and stakeholders it gets more complex, the number of rules or scenarios increase, etc. — it is highly possible the item could not get done in a single sprint. In such a case, the item should be split into two or more new items so their size is manageable in one iteration. And always keep in mind the prioritization of these pieces of requirements so the team knows in which order to tackle them.
When does refinement take place?
This is an ongoing process that, as mentioned above, requires the attention of the entire team. Ideally, refinement focuses on the items for one or two sprints ahead. At the start of a project it may happen that there is not enough product backlog or product backlog items are not completely refined. In this case there is no reason to delay the first sprint until well detailed items are available. The sprint should start immediately and the team should try its best to create a valuable increment with what they have. In the meantime, refinement takes place during the sprint. The team learns and adapts in preparation for the next sprints.
In summary
Refinement is an important Scrum activity that converts the input requirements (the items in the Product Backlog) into ready items for the team to implement as part of the product increment. Not all items in the Product Backlog are required to be refined, just enough to cover one or two sprints ahead. It is fine, though not ideal, to include unrefined items into the sprint backlog with the approval and agreement of the developers. These items are refined during the sprint. Refinement is an ongoing activity in which the whole team participates. This gives them ownership and ultimately increases engagement and optimizes the team’s work.
About
Hi there! My name is Jorge and I have been working in programming for more than 20 years. I’m a certified Scrum Professional Product Owner with vast experience in the Agile Scrum framework in several organizations, industries and technologies. I enjoy teamwork and the creation of great software products.