Some years ago (more than I care to admit), my 200-person team at Microsoft transitioned (as so many have before and since) from the waterfall software development style to agile practices and went through scrum master training. We were interested in how to scale the process to multiple scrum teams, but our two big-name trainers started us with the basics.
After a few introductory slides, the leaders started discussing the sprint planning process and referred to this magical thing called the backlog. I raised my hand and they begrudgingly called on me, presumably wondering how I could already have a question.
“How did the backlog get created?” I asked innocently — OK, not so innocently because we had been using scrum for a while already and I knew firsthand how hard it was to create a perfectly groomed backlog.
They deflected the question despite my persistence and we went on to spend two days learning what is really quite a simple process — that is, if you have a perfectly groomed backlog.
Scrum relies heavily on the existence of a refined backlog. While it isn’t always easy from there on out, an ungroomed backlog can doom your team from the outset.
In this way, it is similar to a lot of the problems teams encounter with scrum – they are mostly upstream of the sprints themselves. For example, agreeing on a definition of done, figuring out how to divide the work into scrum teams, and grooming the backlog are all technically part of agile, but they are often left to the reader. If you do these things poorly, you will be in for a struggle.
With backlogs, the mistake I see most often is that backlog grooming is skipped and grooming is left to be attempted in sprint planning meetings instead. This can lead the development team to feel like the PM isn’t doing their job — and they’d be right!
As a concept, the backlog is really simple. A product backlog is a prioritized list of work that remains to be done by a sprint team. At the front (top) of the backlog are items that are of the highest priority to be completed next.
The sprint planning meeting occurs at the beginning of each sprint. The scrum team selects from those highest priority items (i.e., stories, tickets, tasks — whatever you want to call the “things” that are on the backlog) and assigns them to developers to complete during the upcoming sprint.
A sprint lasts for an agreed-upon duration (usually between one and four weeks) and the team holds a daily standup meeting to make sure everyone is moving forward with their tasks. When the sprint ends, all the work is done, and you rinse and repeat. Congratulations, you are now a scrum master!
Simple, right? Well, yes and no. To enable the team to pick work off the backlog and feel confident in completing it in the sprint, the tasks need to be understood well enough for a developer to execute. Many teams choose to require that they are estimated prior to being taken off the backlog as well.
This process of preparing the backlog for sprint planning is called backlog grooming (aka backlog refinement).
Backlog grooming is a great term because it quickly conveys that the process isn’t a one-and-done activity, but rather something that needs to happen regularly. And that if it doesn’t happen, people probably aren’t going to want to hang out with you — I mean, your backlog.
All the grooming of the backlog doesn’t have to happen in a meeting, but some of it definitely should. It’s not uncommon for teams to forego backlog grooming and just do sprint planning, but this guide assumes that your team has elected to have a separate grooming meeting.
As a PM, I PM everything, even meetings. This means we need a definition of success so we can know whether we have achieved our goals.
Sprint planning is successful when:
I made that last one a stretch goal because, trust me, it’s hard to get a large group of people to agree on this. There will always be outliers that think all meetings are pure evil, that the meeting could have been shorter, or that they needed more time.
Some more basic details about sprint planning:
Beyond that, start at the top with the highest-priority, fully groomed items and work your way down, assigning tasks to specific developers as you go and stopping when the team is full.
If you have done an estimation of tasks in grooming prior to sprint planning (which I recommend), the sprint planning can be as short as 30 minutes.
A backlog grooming session is successful when:
Backlog grooming is where you balance the work of the team to make sure you’re moving forward on your higher-level goals, whatever those are.
Sometimes, that means hitting deadlines. Sometimes, you need to make sure you aren’t completely focused on one or two epics at the expense of others. Sometimes, it means working toward a particular companywide OKR or strategic objective.
Let’s review the basic details around backlog refinement meetings. Many of these elements are less cut-and-dry than those associated with sprint planning and will vary more from team to team.
The list of attendees at a backlog grooming meeting isn’t as set in stone as with sprint planning. However, like the sprint planning ceremony, the product owner, product manager (if that’s separate), and the scrum master must attend.
From the development team, you may include all developers or just the tech lead(s). If you have quality assurance, again, this can mean everyone attends or just the leads. You might also include other stakeholders, such as design, user research, marketing, and customer success, as optional attendees.
This may vary depending on the other meetings in the lifecycle of an epic, but the product manager is most likely to run the backlog grooming meeting. Otherwise, the product owner should run it.
There are a hundred ways to run a backlog grooming meeting. Keep your eye on the outcome you want, which is to get enough tickets “ready” for the sprint — where “ready” means to the point where the dev team indicates that they understand what needs to be done.
Starting points are helpful, so let me share what I do when planning a backlog grooming meeting.
I prepare for the meeting earlier in the day by going through the backlog and deciding what we should talk about (I tag this with “groom”). There is an art to this and you may experience a learning curve when you plan your first few sessions, but you will find your groove, I promise!
I take notes right in the tickets, pull the groom tag off, and mark it ready for sprint (we use a priority flag for this). Sometimes, you discover that more investigation is required (either by the dev or PM), and that’s OK. The task is then assigned to whoever needs to do it. It won’t get a priority tag until that person has done that additional work.
The frequency with which you hold backlog grooming sessions depends on several factors. First, how long is your sprint? The cadence of your grooming meeting will be no more often than that of sprint planning. If you have a two-week sprint, for example, backlog refinement should occur every two weeks at the most, or weekly if you have one-week sprints, and so on.
That said, you definitely don’t need to groom your backlog that frequently. You could double the sprint pace and have a longer meeting, which can be more effective. The frequency will also depend on the overall lifecycle of your features or epics. If you have separate meetings to move them forward, grooming will be faster for those features.
My recommendation is to avoid getting stuck on what other people do; don’t automatically assume they know more than you do. Every team I have been on has different needs depending on the space they are in, how the scrum teams are organized (jobs to be done, focused on the tech stack, etc.), and what is being dictated from above.
That said, in my experience, a typical one-week sprint is structured as follows:
Backlog grooming and sprint planning are both critically important to moving the team forward and meeting your business and customer goals — and they’re also critically linked. These sessions can sometimes feel redundant because you’re looking at the same tickets in each meeting, but they are very different and equally important.
Part of any process is understanding that not everyone on the team completely understands the process, which means you may get complaints about too many meetings. Listen to them, but don’t overreact. If you’re diligent in your grooming and planning meetings, your team will be delivering and that’s what everyone cares the most about in the end.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
This article covers insights for overcoming common challenges, as well as ways to embrace innovative ecommerce strategies.
Dipto Chakravarty, Chief Product Officer at Cloudera, talks about how it takes rigor to design complex technology and user experiences.
As an alternative, this article outlines a case against MVPs, drawing on my own personal experience in the realm of product management.
No product team starts out trying to harm users. However, harm still happens, and often not from one big decision.
Learn more →
