Product backlog refinement (or grooming) is an important activity in Scrum projects where user stories are prioritizes, right-sized and estimated. In his book “Agile Reflections”, Robert Galen provides some hints about how to verify that that product backlog grooming has been done successfully and that the right requirements information is available for the next sprint.
1. Sprint planning is incredibly crisp, short and easy; usually taking 2 hours or less for a 2-week sprint. There are NO architectural or design discussions within the meeting—the relevant parts of these discussions having occurred earlier.
2. As a daily occurrence, team members are talking about epics and stories targeted for 2-3-4 sprints in the future. As a result, everyone is naturally aligning with the Product Owners’ vision.
3. The team easily contributes new stories to the backlog which represents non-feature based work; for example: testing artifacts, non-functional testing work, refactoring, automation development, performance tuning, research spikes, etc. Everyone views it as a shared responsibility.
4. The team has a feel for where the product is going long term and maps efforts, designs, theme suggestions, and trade-offs towards that vision.
5. Each sprint’s goal is easily derived from the backlog; i.e., there is a sense of thoughtful and meaningful story collections or themes that easily surface from within the backlog. From time to time, think of these as “packages” for customer delivery.
6. The Product Owner includes team feedback (bugs, refactoring, improvement, testing, etc.) in EVERY sprint – in some percentage of focus. They clearly show the team that they are listening and acting on their feedback, judgment, and technical opinions.
7. The Product Owner rarely changes priority of elements purely because of size estimates. This doesn’t include breaking them into “now versus later” bits. Illustrating that priority is mostly driven from external business needs that are translated into stories.
8. Blitz planning is done every 2-3 weeks, not only as a planning tool, but also as a risk or adjustment tool. For XP folks, consider release planning as being a similar exercise. The point is end-to-end planning towards the next release milestone occurs iteratively and frequently.
9. Teams are hitting stretch items and pulling in more work per sprint. There is an enthusiasm to deliver more towards goals by creatively trading off story sub-elements. Of course, all of this is heavily collaborated with the Product Owner.
10. The backlog is mapped to the teams’ skills and capabilities, stretching them -yes, but not asking them to do things they are not capable of doing either by skill or experience.
11. Within every sprint, the Product Owner is making micro-adjustments to scope based on interactions with the team. Always striving for that Minimal Marketable Feature and Product set!
12. The team is never surprised in sprint planning. Not even by a single story. I know, change is supposed to happen, but surprising the team with last minute changes…is not! Instead, make it wait till the next sprint.
13. The team feels they have a say in what’s on the backlog and the distribution of features vs. improvement items. However, they can’t be solely parochial in their views. They need to make a business case from the customers’ point of view, for all nonfeature work introduced into the backlog; they do this willingly and effectively!
Reference: Agile Reflections – Musings toward becoming “Seriously Agile” in Software Development, Robert Galen, https://leanpub.com/Agile_Reflections
This list shows the importance of having the Scrum team involved in this practice. The good results of a backlog refinement meeting are achieved through a cooperation between the product owner and the development team. All participants have to provide their own perspectives of the user stories and to understand the needs and concerns of the other participants.
Further reading
Tips for Effective Backlog Grooming
Cheat Sheet for Product Backlog Refinement (Grooming)
8 Rules for Backlog Refinement: Building Blocks for Sprint Planning
It is always “garbage in, garbage out” and Agile will not solve the problem of bad requirements, maybe only make it more obvious quickly.