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.
Table of contents
- Why backlog refinement is crucial for sprint planning
- What is a product backlog?
- What is sprint planning?
- What is backlog grooming?
- What does successful sprint planning look like?
- What does successful backlog grooming look like?
- Are backlog grooming and sprint planning redundant?
Why backlog refinement is crucial for sprint planning
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!
What is a product backlog?
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.
What is sprint planning?
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.
What is backlog grooming?
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.
What does successful sprint planning look like?
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:
- Every developer knows what to do when they leave the meeting
- Every developer feels reasonably confident that they can finish what is assigned to them by the end of the sprint, according to the agreed-upon definition of done
- Attendees agree that the meeting was a good use of time (stretch goal)
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:
- Who attends the sprint planning ceremony? The sprint team, product owner, scrum master, and product manager (if that role is separate)
- Who runs the sprint planning meeting? A scrum master or product owner
- How long is a sprint planning session? 30–60 minutes
- How often should sprint planning occur? The duration depends on the sprint length
- Do you need to set a sprint goal? It’s not necessary to have a sprint goal, but it can be useful to help you decide what to take off the backlog. This is a way to focus the team on backlog items that are related to each other and align to create a larger outcome
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.
What does successful backlog grooming look like?
A backlog grooming session is successful when:
- Sprint planning is successful
- You are making progress on all of your epics
- You understand where you are relative to impending deadlines
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.
Who attends a backlog grooming meeting?
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.
Who runs a backlog grooming session?
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.
What is on a backlog grooming meeting agenda?
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.
How often should backlog grooming occur?
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:
- A product team meeting every month where we decide what is greenlit for the product team to start specifying (90 minutes)
- When a feature is large enough, a weekly meeting with all the stakeholders to specify the feature (1 hour)
- When the feature is specified to the point where I am ready to write tickets for it, the items go in the backlog
- Backlog grooming meetings for each team every other week (1 hour)
- Weekly sprint planning (usually 30 minutes long; scheduled for 1 hour to be safe)
Are backlog grooming and sprint planning redundant?
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.
The post Why you need a perfectly groomed backlog for sprint planning appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/O08ABzQ
via Read more
