I recently heard someone say “I think backlog grooming1 and sprint planning are the same thing”. I can see exactly why someone might think that. So I thought we could take a look at the intent behind backlog refinement (as it’s called now) and sprint planning. Let’s go!
Backlog Refinement
A backlog refinement ceremony is an event where the team looks at the backlog of work items. They have the opportunity to review the stories and acceptance criteria, ask questions, and get clarifications. The biggest problem with consistency is that backlog refinement isn’t one of the described ceremonies in Scrum. Because of this, people have different ideas about the goal and structure of backlog refinement.
So, since there’s no clearly defined structure for a backlog refinement meeting, let me provide some recommendations for what I look for in a successful ceremony.
Review of Upcoming Work
The biggest benefit for holding a backlog refinement meeting is to give the team some visibility into the work that’s being proposed to work on next. Simply knowing what’s coming up next can give the team a good grounding for the next sprint. It may even improve the current sprint’s quality or focus. We don’t want to change what we’re doing during our current sprint, but it may influence which solution the team picks. Knowledge of short-term future plans can help solidify that decision-making process. Keep the review to the next sprint or two at most. There’s no reason to be reviewing the entire backlog!
Estimating Highest Priority Items
Another success criteria I have for this meeting is that the team can estimate the work at the top of the backlog. We could wait until sprint planning, but if we can estimate it during refinement we’ll know that we are probably “right-sizing” the stories and that we have sufficient detail. If we can’t estimate a story – for whatever reason – this is an indication to the Product Owner that they need to do some research, provide some more detail, or work with the team to decompose that story into smaller pieces. If we don’t do this in advance, we may get to sprint planning and find the stories are too large. This helps prevent that scenario.
Use in Agile at Scale
Backlog refinement is critical to our success when we scale agile (using SAFe, LeSS, etc). Only by getting alignment and transparency across a team of teams can the whole team be successful. The best way to do that is to give individual teams visibility into upcoming work. This allows them to understand the dependencies across teams, stories, and features. Especially in a framework like SAFe, backlog refinement is vital for a successful PI planning event.
Sprint Planning
Now that we’ve talked about backlog refinement, what’s different about sprint planning? The biggest difference is that in planning the team will be making a commitment to the work.
The agenda for sprint planning is pretty well established. The team determines their capacity (or planned velocity) and then assigns work to their sprint backlog until they hit that capacity. The team reviews the acceptance criteria and might revisit their Definition of Done. It may also spur a conversation about their Definition of Ready (if they have one).
One practice I recommend during sprint planning is decomposing the stories into tasks. I do know some coaches think this is a waste of time. With high-performing teams, it might be, but in my experience, teams new to Scrum (or even still in the “norming” phase) may bring more work into the sprint than they can handle or assign more work to one individual than that person can possibly complete. Tasking gives us a checksum on our planning. If someone’s on vacation, that may not be covered adequately in the team’s capacity. When we break our stories into tasks, we find these gaps and can correct them.
@ Velocity
Here at Velocity, I’m a strong proponent of using the backlog refinement meeting to really get the Product Owner and the teams in sync. Not every team does one (for a variety of reasons), but it’s a good practice and I encourage it. When I was a developer, I found it very useful to know what was being proposed in upcoming sprints.
For Sprint Planning, I would recommend decomposing stories into tasks as the biggest “bang for your buck”. If your teams can improve their committed vs. delivered percentage they’re going to see more productivity and develop a great sustainable pace. Both of those things help our “norming” teams become “high-performing” ones.
Closing Thoughts
While sprint planning is a vital part of any Scrum team, backlog refinement is a ceremony many teams don’t do. In my coaching engagements, I like to make sure – especially with new teams – that they get as many opportunities to be successful as possible. Much of that success means understanding what is being requested and how that work ties to customer value.
In terms of cadence, I would recommend starting by holding a backlog refinement ceremony once a week. Once your team gets the work for the next sprint or two, you can probably move that cadence to once per sprint. With a once-per-sprint cadence, your teams should be able to stay ahead of the work.
Adding the backlog refinement meeting to your regular cadence should give your teams visibility, focus, and understanding. By setting them up for success, our teams can become the high-performing teams we all strive to have.
Felix entrenamiento, mis amigos! (Happy coaching, my friends!)
Notes
1. Most agile people use the term “backlog refinement” now due to some unsavory interpretations of the word “grooming”. Many people who learned the term years ago still slip and use “grooming”, but the preferred term these days is “backlog refinement”.