Backlog Grooming – An Essential Guide

1. What is backlog grooming?

Backlog grooming sessions are designed to help product teams improve development processes and ultimately assist the whole team in building better products.

Backlog grooming is also known as sizing, backlog prioritisation or a refinements session. The goals of each these sessions are largely the same: to reduce the amount of ambiguity and increase the clarity in understanding by the team about the upcoming stories / tasks in the backlog.

As a product manager, you’ll eventually develop a strange emotional connection with your backlog. Over time, your backlog becomes the beloved pet you never knew you wanted. And just as you’d nurture and groom your own pet, you’ll do the same with your backlog. You’ll have it open in your browser, you’ll check it out first thing in the morning and last thing at night. Like a tamagotchi with bugs.

Types of backlog

Product managers love backlogs. We love lists of things to do, ideas, problems and records of things that need fixing. There are so many different types of backlogs that product managers keep:

Development backlog – your main backlog is the backlog which dictates the actual work that will be done in your engineering sprints

Business / stakeholder backlog – a dumping ground for stakeholders throughout the business to dump thoughts, problems, ideas and issues. This can be categorised to help assessment but is typically a place where you allow your stakeholders to dump things so that they feel as though they are being listened to by the product team. The business / stakeholders don’t need (or want) to see your development backlog. Stick to using a business backlog for collecting ideas and your roadmap for communicating product updates and your strategy.

Experiments backlog – if you regularly run experiments, you’ll dump the experiment hypotheses / ideas somewhere. This can be an experiment backlog set up in a Trello board or similar project management tool.

Design backlog – often, you’ll have design teams working on separate streams of work. This can (but not always) involve managing a separate stream of work in a separate backlog specifically for your design / UX teams.

Your development backlog is the backlog that needs grooming on a regular basis since this is the backlog that is used directly by the engineers who are building your product. If your backlog is left unloved for a while, it will start to resemble an unkempt, stray dog, so it’s important to pencil in sufficient time to give your backlog the love it deserves.

The benefits of backlog grooming

There are real tangible benefits to grooming your backlog:

Efficiency – grooming ensures the items at the top of the backlog are ready for delivery in your upcoming sprints. Nothing slows down your efficiency more than a backlog that is full of ambiguous, poorly-defined user stories that the development team have never seen before.

Clarity – grooming gives your development team the time and space they need to clarify outstanding questions and queries regarding user stories. You really don’t want your planning sessions to be too bogged down by questions regarding upcoming stories. Ideally, you will use your grooming sessions to clarify questions so that on sprint planning day your stories are not new bombshells that have arrived out of the blue. The team will be familiar with the story since you’ll have talked about it in your previous grooming sessions.

Estimation – one of the primary purposes of your backlog grooming sessions is to estimate the stories in your backlog. Different teams employ different ways to estimate stories. No estimation process is perfect and it’s true to say that the more unknowns the less accurate the sizing. Eliminating as many unknowns as possible will help you to increase the accuracy of your sizing method. Decide on a method for your team and use the method for as long as you feel it meets your requirements. Typically, T shirt sizes work well for large scale ambiguous items in roadmaps and fibonacci numbers work for individual user stories.

Re-evaluate – your grooming sessions allow you time to re-estimate and re-evaluate stories based on new discoveries / information. Often, you won’t have all the information to hand so you’ll need to do more analysis before you’re ready to size. Armed with your new information you can re-evaluate the story.

Hygiene – over time, your backlog will get messy. Use your grooming sessions to remove unnecessary clutter from the backlog. This includes bugs, old stories, technical chores and other clutter which may be clogging up your backlog. For hygiene grooming sessions, it’s sometimes best to speak to 1 or 2 members of the team who can clarify if a bug is still valid or a technical chore is still required.

Your grooming sessions are an essential part of the agile product development process.

2. When should you run backlog grooming sessions?

As you’re no doubt aware, a typical agile product development process comprises various standard meetings. These include:

Sprint planning – your planning session is where you articulate the work you’re prioritising for development in this sprint and why

Daily stand up – your daily stand up is where you assess the progress of the items in development on a daily basis and your engineering teams flag up any blockers or impediments

Retrospective – your retro is where you discuss the problems you experienced during the sprint in an attempt to get rectify problems and improve your product development processes

The way in which backlog grooming fits into this process can be agreed by you and the team.

Here are a few options:

Towards the end of the sprint

Mid sprint

On an ad-hoc basis

The timing of your backlog grooming session largely depends on the amount of work you have to do, the size of your team, the lifecycle of your product, the stage of your new project or feature and the nature of the work or projects required.

Typically, at the earlier stages of a large scale project you’ll need more scoping sessions with your team to explain the goals of the project and uncover any early impediments. As you progress through a large scale project you’ll reduce the amount of ambiguity which means you’ll need less grooming sessions.

A backlog grooming session should ideally take place at least once every sprint. If you’re running a fortnightly sprint cycle this means at least 1 backlog grooming session per sprint. This will give the team plenty of time to ask questions, size stories and get a clear understanding of what’s required before your planning session.

A good rule of thumb is to try and aim to be at least 2-3 sprints ahead of your team. If you reach this comfort zone, your grooming sessions can be fortnightly. If you’re not quite there yet, keep grooming the backlog until you reach this sweet spot. It rarely happens, but if your backlog isn’t sufficiently groomed, unforeseen business changes can force sudden and unexpected changes in your backlog which lead to your previously prioritised stories being changed, de-scoped or binned altogether. In these instances, if you’re 2-3 weeks ahead you’ll have other work the team can pick up instead.

3. How to run a backlog grooming session

Before the session

As with most meetings, the key to success lies in your prep work beforehand. A grooming session can descend into an unstructured, chaotic mess quite quickly so it’s best to put in some effort upfront to avoid it.

Everyone should aim to be prepared before the meeting. For the product manager this means prepping story details, for the UX / design teams, this means finishing mock ups if they are required before a session, for engineers this could mean reading through the stories / tasks beforehand.

Don’t fret about having all the details upfront. Sometimes you’ll be waiting on other parts of the business to confirm specific details or you’ll not be 100% certain of how a feature may pan out in all cases. Explain to the team that there is, and always will be, a certain degree of ambiguity; the purpose of your grooming session is to reduce this through dialogue with the team.

Revisit your roadmap and quarterly goals – give yourself a refresh on what your roadmap and goals state for your product. You’re prioritising stories before the grooming session. If your stories bear no relation to your roadmap and goals reconsider their priority.

Get stakeholder input – you’ll no doubt be doing this anyway, but before you create your user stories, make sure you have relevant input from your stakeholders. For some stories, your requirements should clearly match the expectations of your stakeholders. If you are yet to discuss anything with your stakeholders and you know that their input is crucial for this particular story, hold off sizing until you have the relevant input.

Prioritise the backlog – since the backlog grooming session is centered around the backlog itself, ensuring your backlog is up to date and prioritised accordingly is a must. Before your session, decide which specific stories, bugs, chores, tasks you want to talk through with the team. If possible, send these around before the meeting so your team have a chance to read through them.

During the session

Your backlog grooming session is an opportunity for your team to clarify story requirements and to clean up your backlog.

On a practical level, pick a time, day and room which facilitate a healthy group discussion. This means not being boxed into a room with no windows, no seats and no screen to follow the backlog which can happen if you’re left with the dreaded meeting room of doom which nobody wants!

To make your meeting as efficient as possible, follow these rules:

Timebox to 45 mins – 1 hour – any meeting that goes on longer than 45 minutes will end in tears. The human brain is only able to stay focused for a short period of time. Give yourself 1 hour in total, with a few minutes to allow for latecomers and questions / quibbles.

Move on – avoid spending longer than 15 minutes on any 1 story if possible. If you start to overrun on a particular story and you have more items to get through, set up a follow up meeting for that particular story or feature. If it’s resulting in a long debate that doesn’t necessarily mean you shouldn’t have that debate, but that it isn’t the best use of everyone’s time. Set up a separate session with the people involved to resolve the outstanding issues.

Explain the why – where possible provide data and business rationale to explain why stories are relevant. Link the stories back to the overall big picture.

Admit defeat – if you find yourself in a situation where there’s clearly detail lacking in a story at this point in time and you’re clutching at straws it can be tempting to get on the defensive and explain why the extra detail isn’t relevant. Don’t get on the defensive – if everyone in the team agrees that there’s insufficient detail in the story to either size it accurately or to make a particular technical decision, come back to it at a later date.

Make decisions; different problems will need a decision to be made by different people. Often, decisions will need to be made by you as the product manager. Don’t feel pressured into making a decision on the spot. You may need some time to assess options before deciding on a specific route. If you’re unable to make a decision on the spot, be clear about what the options are and what the next steps are to get to a decision. Equally, if you have made a decision, make it clear that a decision has been made.

Whilst grooming sessions are fundamentally important in reducing ambiguity and increasing clarity, grooming backlog sessions should not be used for a major project kick-off sessions. For example, if you’re going to be undertaking a major piece of work that’s likely going to take 3 months +, you should not be jumping straight into grooming tickets. You should instead have a project kick off with the entire team where you clearly articulate the project goals, understand what the overall development approach will look like and identify any major potential technical blockers as early as possible.

After the session

Your grooming session should help you to reduce ambiguity and uncertainty in your backlog. After the session, do a little post-meeting pruning of your beloved backlog to make sure it’s now in a healthier place. Be clear about what the next steps are and take some of these practical steps if necessary:

Send around any follow up notes – if an important decision was made or an ambiguous point was clarified, send around some follow up notes to clear up any outstanding ambiguity and make it clear that a specific decision was made.

Re-engage with your stakeholders – often, a backlog grooming session can throw up unexpected potential technical blockers or questions that you were not able to answer until you got further details clarified from other parts of the business. Re-engage with your stakeholders with the aim to both inform them of any relevant potential blockers and impact to timelines and to get answers to outstanding questions and details about particular stories.

Smaller follow up sessions – If needs be, set-up, smaller break-out meetings to discuss big ticket items with a lead engineer. Be very pragmatic about why and when you may need to pull someone out of the sprint.

Once you have completed relevant follow up meetings and clarified outstanding details, take the time to revisit your backlog. Add further details to stories that were lacking in detail, break large tickets down into smaller stories and make sure you have the necessary details prepared for your next session. In product management, building product never stops. And your backlog never stops growing.

Useful tools

If you’re going to show your backlog the love it deserves, you’ll need the tools to help you do it. Here’s a selection of tools to help you groom your backlog.

Jira –
hideous in places but gets the job done. One of the most popular tools for managing your overall engineering backlog.

Pivotal Tracker – another popular tool that’s used for maintaining your engineering backlog. It’s more pleasant to use in Jira in places but can be a little tricky to distinguish between the backlog and the current sprint.

Trello – perfect for gathering input from stakeholders in your business / discovery backlog. When you’re gathering input from stakeholders, the simpler the better. Trello is now owned by Atlassian, owners of Jira. Fingers crossed they don’t destroy it!

Google Drive when in doubt, set up a simple Google Sheet to gather info in a spreadsheet. The biggest downside of this is not being able to easily drag and drop items.

ProdPad primarily a roadmapping tool to make beautiful roadmaps, ProdPad also allows you to manage a backlog.

Thank you for your article!
It looks really helpful and the selection of tools for grooming is also great.
There is one more smart tool that can supplement your tools’ list thanks to it great opportunities for feature prioritization. It’s Hygger.io where you can find 4 types of scoring: Value and Effort, RICE model, ICE scoring and Weighted scoring by customed criteria. https://hygger.io/blog/new-features-hygger-rice-ice-prioritization-types/
All of the frameworks will definitely help to improve the ability to prioritize and maintain backlog.