THEORY IS WELL... THEORY
What is backlog grooming?
First of all, what is backlog grooming, also known as sizing or backlog prioritization? Well, it’s a way to improve your team’s clarity when it comes to upcoming stories and tasks in your backlog. It’s basically designed to help improve development processes for product teams, so that they can deliver better products.
If you’re a product manager, you’ve probably already developed a special connection with your backlog, and so just as you would groom your pet, you do the same with your backlog; hence ‘backlog grooming’!
There are types of backlog
To keep track of things – i.e. ideas or problems that need 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 are building the product. It’s the one that sets the tone for the actual work you’ll be doing in your engineering sprints, so make sure you don’t deny your backlog the love it deserves.
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 you can 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 for design/UX teams to work on separate streams arises.
Gains from backlog grooming
The benefits of grooming your backlog are pretty real:
Efficiency – first and foremost, grooming makes sure the items at the top of your backlog are ready for delivery in your upcoming sprints. Nothing messes with efficiency more than a backlog full of poorly-defined user stories.
Estimation – one of the main purposes behind backlog grooming sessions is to estimate the stories in your backlog by trying to eliminate as many unknowns as possible.
Clarity – grooming sessions ensure your development team has the time and space needed 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 make sure of that.
Iteration – your grooming sessions allow you to re-estimate stories based on new information. You might not have all the info at hand, so spend more time on analysis before you’re ready to size.
Cleanliness – over time, your backlog will get messy; that’s for sure. Use your grooming sessions to remove bugs, old stories and other clutter from your backlog.
When to run a backlog grooming session?
First of all, the timing of your backlog grooming session is mostly based on 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 though, 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 give the team plenty of time to ask questions, size stories and get better understanding of the requirements before 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.
PRACTICE IS A DIFFERENT STORY
All of this is sweet, but practice and theory don’t always meet. 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.
While backlog refinement sessions start off innocent, problems can slowly creep into your process; forgetting which tickets have already been reviewed, spending too much time on a ticket, or discussing every technicality in existence! So, if you’re hating backlog refinement, that’s fine; hating it happens to also be the path to fixing it.
The meeting that shouldn't be
When your backlog refinement meeting is anything less than a time for communication, productivity and fun, then know your approach isn't working. Failure also includes having one or two people telling the team things they already know; the product owner spending the meeting assigning tasks to the team instead of working together on defining features and stories; meetings always going on past schedule, or being way longer than needed, and so on.
The mindset you should’ve had
The mindset you take into your backlog refinement session in many ways 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. 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 can basically make or break the backlog refinement experience. Backlog refinement is supposed to be a collaborative process, not a task-management session, and so a product owner who uses it as an opportunity to micromanage everyone's schedule is definitely not doing it right. On the other hand, if they’re not involved enough, then the backlog refinement will inevitably run into quality and dependency problems in sprints. And if they’re unprepared, they’re wasting everyone’s time.
The backlog that could’ve been simple
It's possible to go too far and overly define your backlog; no need for that. As you move through your product roadmap, you’re continually adapting, and so an overly refined backlog steals precious time from important tasks, and that, for stories likely to change in the future.
YOUR SOFT SOLUTION
To give you a few recommendations on how to run proper backlog grooming sessions.
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, maybe going through the stories / 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, 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
If you’re having trouble with your product backlog, then you might just need 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’ might not be the solution when you have an unable product owner on board.
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 prioritization. Use an existing 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 a backlog priority application; Foxly is such an app and it integrates with Jira. It allows you to manage and update priorities in an interactive table, and visualize thanks to a priority matrix that highlights low hanging fruits. 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.