The art of running a backlog refinement (grooming) session.
When and how should PMs lead backlog grooming?
A Google search and you’ll find dozens, hundreds, of articles on backlog refinement or grooming activities. At some companies, PMs don’t even perform this activity because it’s considered too tactical, delegated to tech leads/engineering managers, scrum masters, or designers. But backlog grooming doesn't have to be just tactics.
What is backlog refinement (a.k.a. grooming)?
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 [within product delivery] to add details, such as a description, order, and size.
The Scrum Guide
How does it differ from sprint planning?
The sprint planning session results in a commitment by the product team to specific work during the sprint whereas backlog refinement is a planning activity, to explore possible work in the future.
Three simple steps to run backlog refinement
Prepare: Identify a max of ~15 stories for discussion.
Why 15? The meeting is timeboxed to 60 minutes. 60 minutes ÷ 15 stories equals 4 minutes per story. Not a lot of time when you have multiple people involved. Remember, the goal is for more clarity and precision, not end the meeting with a bunch of open-ended discussions. Stick with fewer stories and it’s better to end early.Categorize: Bucket into three groups
Problems/ideas stories -> Stories that are problem statements or solutions to possible problems.
Development stories -> Stories that are developed, committed solutions. You’re probably most familiar with these.
Feasibility spikes -> Stories to uncover an unknown.
The grouping helps you identify the type of backlog refining session it’ll be. Whereas problems/ideas stories will solicit discussions around problem framing and solution brainstorming, development stories are more around breaking down tasks.
Second, like other planning activities, there’s some unknowns. Often, these unknowns are software engineering specific, but they can also be exploration into business, legal, or finance unknowns. Feasibility spikes stories help surface and explore the unknown.
Set aside 60 minutes.
Longer and you’ll need breaks because people will lose attention. Less than 30 minutes and the effort to organize everyone (i.e., startup cost) is too high. Hold backlog refinement just before the midway point of your current sprint. If you hold them at or after the midpoint, everyone’s attention is focused on completing the active sprint rather than backlog refinement.Assign someone else to lead when reviewing each story.
It’s common for PMs to lead backlog refinement. You’ve set up the calendar invite and selected the stories for discussion. However, you don’t have to run the meeting. Similar to my advice in running sprint demos, assign someone else to lead the meeting.
This accomplishes two things: It requires active engagement from others on the product team, whomever is leading. At the same time, it frees you up to actively listen and take notes or update the stories with additional details.
Principles for good backlog refinement
Focus discussion on exploring unknown dependencies, execution risks, and work sequences. Ask questions such as:
Break down work-> How would we execute the story? How would we break down the work?
Identify dependencies prior to starting work -> What kind of help might I need to complete the story? Would we need something (work/help/support) from someone else before we can (start/finish) the task?
Identify work others need to do after work is finished -> Once done, does the work impact someone else in the company? After the work is complete, does someone else need to do something?
Identify risks and voice unknowns -> What’s a big unknown that’s making us scared to do this work? What’s something that feels scary about this work?
Set a ratio of 10%:80%:10%.
For established products, it’s normal to have 1 - 2 problem/idea stories, 8 - 10 development stories, and 1 - 2 feasibility stories. If you have a lot of problem stories, it signals you need to spend more time prioritizing which problems to solve.It’s okay to have less experienced engineers and designers lead backlog refinement.
If the person leading the backlog grooming doesn’t have confidence because of inexperience, they may feel inadequate to lead the discussion. Assure the person, the feeling is okay. You can reduce the number of stories to ~6 - 8 to not overwhelm the person when you start.It’s okay if you don’t estimate effort/time.
Many backlog refinement articles talk about it’s important to estimate work efforts during backlog refinement. I disagree. First, you still have sprint planning, which is where you need to estimate effort to commit work. Second, backlog grooming estimates are usually to help with more general planning. If you have a hard commitment date project, you’ll have already done this during project planning, so you should refer to your project roadmap. If you don’t have a project roadmap, then this isn’t actually necessary.Assign work to yourself.
PMs write stories for others, but it’s just as important to write stories for tasks you have to complete. It’s a public to-do and your tasks are often needed dependencies before the work can start or finish.Delete old stories in the backlog.
I know many PMs feel you shouldn’t delete old stories. Instead, they create categories and lump dozens or hundreds of stories together. These are called Archive, Icebox, Ideas, To-Do, etc. Sometimes, there’s even sub-categorizes underneath.My recommendation is to delete any backlog story that’s older than 6 months.
Why?
If it was a priority, you’d have gotten to it. Facing reality isn’t a judgement of good or bad. It is what it is.
Nothing prevents you from recreating the story when it becomes a priority in the future.
Information on those stories is stale. You’re going to have to do re-work regardless.
Reducing clutter helps you make more space
Source: