4.6: Product Backlog Refinement - Video Tutorials & Practice Problems
Video duration:
5m
Play a video:
<v ->To keep the product backlog healthy,</v> the team needs to continuously refine it. Backlog refinement is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure that the backlog contains the appropriate specifications. They need to make sure that those requirements are prioritized, the right items on the top of the backlog and are ready for delivery. This activity occurs on a regular basis and may beneficial the scheduled meeting or an ongoing activity. The overall intent of backlog refinement is to ensure that the backlog remains populated with items that are relevant, detailed, and estimated to a degree appropriate with their priority. And also, it's important to keep the backlog up to date, meaning in line with the current understanding of the project or product and its objectives. Some of the activities that happened during the refinement, include, first, removing user stories that no longer relevant, second, creating new user stories in response to the newly discovered needs, re-assessing the relative priority of stories, assigning estimates to stories on the top of the backlog, correcting any estimates in light of the newly discovered information, and finally, splitting user stories or decomposing user stories that are high priority but too significant in effort to feed the upcoming Sprint. Product backlog refinement usually was called backlog grooming. The earliest recorded use of the term backlog grooming is from Mike Cohn, who is the guru of agile requirements management, and he started using it in 2005. Grooming was originally used to reflect on organic approach to product backlog maintenance. And the use of the word grooming had some negative connotations in some cultures. So this specific activity has been renamed to backlog refinement, but many practitioners still use the word grooming. If you hear backlog grooming, it is a synonym to backlog refinement. There are overall different practices in terms of frequency of product backlog refinement and ownership of this event. This practices differ between organizations. Some teams schedule refinement sessions as part of the Sprint cadence and have all team members participate in those sessions, discuss user stories, align on estimates and take action items to find the missing details. In some other organizations, the ownership is with the product manager and product manager will make decisions upon consulting with the relevant stakeholders and make their backlogs available to team members for review and feedback. And product manager could be the same person as the product owner or could be a separate person for a large products, where there are several sub-products involved that needs coordination and alignment in terms of decision making. Overall in my experience, the more collaborative and structured the approach is, the more well defined it is, the less room is there for scope creep. For any misunderstanding, any confusion, any change in scope. Overall, there are several principles to follow. Number one, product backlog refinement is not limited to the refinement session. The product owner has to set clear vision communicated to the team, aligned with the stakeholders and continuously remind them what is the true north. What is the objective they want to achieve? The second is that product owner is in constant contact with the business and also the technology stakeholders. This means that there are no surprises that specific user stories are getting deprioritized and a business stakeholder is upset about it because they need this functionality. And some of those are not included in the backlog and that's even worse misalignment situation. So overall I do not suggest deleting ever any user stories that you have on your backlog. If they're no longer needed, cancel them, and put in comments why you have chosen to do so and let's keep them there for the record. The third principle is that the workload for the backlog elements has to be very well-defined and communicated. This includes your intake mechanism, any categories, any expected format, approvals, and so forth. Usually it is done off the working agreement of the team. In the working agreement, the team defines the rule and practices and behaviors how they want to work together, and putting your intake and decision making for your backlog in the working agreement is usually a good idea. And remember, if a requirement is not in the backlog, it does not exist. Always resists the anti-pattern of doing work of the books even if can be absorbed within the current Sprint and even if it is the right thing to do for your product, put it in the product backlog. Your backlog is the documentation for your product. So if any undocumented work will go into production, it'll create issues with extending or removing any related functionality in the future. So remember the mantra, if it is not in the backlog, it does not exist.