If you’re a product manager, it's safe to say you've already developed a connection with your backlog, and so just as you'd groom your pet, you'll be doing the same with your backlog hence the expression ‘backlog grooming’!
First things first, what is backlog grooming?
Backlog grooming, also known as sizing, backlog prioritization or product backlog grooming is a way to prioritize work while helping your team clarify upcoming stories and tasks in the backlog. It’s basically designed to help improve development processes for product teams, so that they can deliver better products.
There are different types of backlog
To keep track of things such as ideas or problems that require fixing, product managers make use of a few backlog types.
The development backlog is the one that needs grooming on a regular basis since it’s the one used directly by engineers who build the product. It’s the one that sets the tone for the actual work you’ll be doing in your engineering sprints.
Business / stakeholder backlog - the dumping ground for thoughts, ideas and issues - is where stakeholders feel they’re being listened to.
Experiments backlog is a backlog that can be set up in a Trello board or a similar project management tool, for those who regularly run experiments.
Design backlog is for when the need arises for design/UX teams to work on separate streams.
Gains from backlog grooming
The benefits of grooming your backlog are many.
Efficiency – first and foremost, grooming ensures that the items at the top of your backlog are ready for delivery in upcoming sprints. Nothing hurts efficiency more than a backlog that's full of poorly-defined user stories.
Estimation – one of the main purposes behind backlog grooming sessions is to be able to somewhat estimate backlog stories by eliminating as many unknowns as possible.
Clarity – grooming sessions ensure your development team has the time and space they need to make sense of outstanding questions and queries regarding user stories. Your team should be familiar with a story before sprint planning day is here, and so grooming sessions help with that.
Iteration – your grooming meetings allow you to re-estimate stories based on new information. You might be missing some of the info you need, so spend time analyzing before you’re ready to size.
Cleanliness – over time, your backlog is bound to get messy which is why grooming sessions are used to remove bugs, old stories and any other clutter from the backlog.
When to run a backlog grooming session?
First of all, the timing of a backlog grooming session is based on a few factors such as the amount, nature and stage of your work, the size of your team, and the product lifecycle. During earlier stages, say of a large-scale project, you’d need more scoping sessions with your team to explain the project’s goals and uncover early blockages. As you progress however, you’ll hopefully be able to reduce ambiguity, which means fewer grooming sessions.
A backlog grooming session should ideally happen at least once every sprint. It will allow the team to ask questions, size stories and get better understanding of the requirements before moving on to the planning session. A good way to do it is to be at least 2-3 sprints ahead of your team, that way you only need a session every couple of weeks.
The reality of never-ending grooming meetings
All of this is sweet, but practice doesn't always meet theory. In the real world, too many companies suffer from never-ending grooming meetings. And the worst part is that the results aren’t even that good to make up for the suffering of those involved.
While backlog refinement sessions may start off innocent, problems can slowly creep into the process. Problems include forgetting which tickets have been reviewed already, spending too much time on one ticket, or discussing every technicality in existence! So, if you’re hating backlog refinement, that’s fine; hating it can also be the path to fixing it.
The backlog meeting you could've skipped
When your backlog refinement meeting lacks communication, productivity and fun, then know your approach isn't working. Failure also includes having one or two people telling the team what they already know; the product owner spending the entire time assigning tasks as opposed to working together on defining features and stories; meetings always going on beyond schedule; or the loudest person in the room basically taking over.
The mindset you should’ve had
The mindset you bring with you to the backlog refinement session determines what you get out of it. If figuring out how to best deliver value isn’t your goal, you’re not going to get much out of this; and that’s even harder when your meetings suffer from what I’ve already mentioned above. Backlog refinement only works when every stakeholder is engaged and empowered to share their view, ideas, and concerns. Otherwise, what’s the point?
The product owner who could’ve made it
The product owner is able to make or break a backlog refinement experience. Backlog grooming is supposed to be a collaborative process, not a task-management session, so when a product owner takes it as an opportunity to micromanage everyone's schedule, then no wonder it's hell. On the other hand, if the product owner isn't involved enough, then backlog refinement will inevitably run into quality and dependency problems in sprints. And finally, if they’re unprepared, they’ll end up wasting everyone’s time.
The backlog that could’ve been simple
It's possible to go too far and overly define your backlog. As you move through your product roadmap, you’re continually adapting, which makes an overly refined backlog steal precious time from important tasks, especially that stories are likely to change in the future.
Soft solutions for better backlog grooming
To give you a few recommendations on how to better run backlog grooming sessions.
Prepare beforehand
As with most meetings, the key to success partly lies in the preparation work beforehand. For the product manager, it’s the story details; for the UX / design team, it’s the mock ups; and for the engineers, it could be about going through stories or tasks first.
Revisit your roadmap and goals and how connected they are to your stories; if not much, reconsider their priority. Get stakeholder input and make sure your requirements clearly match expectations. Also, before the session, decide on the stories, bugs, tasks you want to discuss and send them out to the team.
Create a conducive atmosphere
Your backlog grooming session is a way for your team to clarify story requirements and clean up the backlog. Try to choose a space that encourages group discussion, maybe something a little more conducive than a boxed room with no windows.
Set up a time limit
Meetings that go on longer than 45-60 minutes lose their efficiency, so make sure you maximize the impact of that one hour. Avoid spending longer than 15 minutes on a story, and if needed set up another meeting for that particular story.
Take your time deciding
Take your time when assessing options, and once you do, be very clear about it. And while grooming sessions are super important to increase clarity, they’re not major project kick-off sessions.
Follow up on things
After the session, do a little post-meeting cleanup of your backlog to make sure it’s at its best. Send follow up notes to clear up outstanding confusion and re-engage with stakeholders to inform them of potential blockers as well as get details about specific stories.
The other (hardcore) solutions
Remove the product owner
Ok, this may sound extreme but bare with me. If you’re having trouble with your product backlog management, then you might simply need to find another product owner. No offence, but an able product owner gets the job done; that includes writing proper user stories, learning and adapting, and so on. Inventing ‘grooming’ may not be the smartest thing to do when your product owner is simply clueless.
Kill the grooming session
On the other hand, if your grooming sessions are killing your productivity, then kill the grooming meetings; as simple as that. You can remove the meeting entirely if the product owner is able to manage prioritization on their own while refining user stories in collaboration with the team. Killing the grooming session makes sense when someone keeps hijacking the sessions to change priorities and user stories on the fly, or if the sessions are too long (over an hour) and the result is poor.
Eliminate bias with prioritization
If you want to keep the session though, it’s important you eliminate bias which you can easily do with proper backlog prioritization. Use an existing prioritization model such as one of the models in this article or (even better) agree with the rest of the team on your own scoring model.
The product owner can propose a model that stakeholders need to contribute to and validate, then use it consistently.
Use a backlog prioritization app
Another super solution is to use an agile backlog management application such as Foxly which fully integrates with Jira. It allows you to manage and update priorities in an interactive table, and visualize thanks to a priority matrix that highlights quick wins. Foxly allows you to eliminate bias features, and is fully customizable, so if you’d rather tweak the model or create it from scratch, you can.
