TL;DR – Your Sprint Planning Meetings don’t have to be a chore. Your Sprint Backlog doesn’t have to be a mess. Do short backlog refinement meetings twice a week and sleep a lot.
Our Hero Takes a Nap
I was working on a performance problem in some code last week. An operation that gets run a lot had over time become insanely slow. I spent a day working on it and no matter what I modified, it barely made any difference. I just couldn’t figure it out.
The next morning, literally as soon as I woke up and opened by eyes I knew exactly what the solution was. About an hour of coding later and what was taking >20 seconds to run was now taking only 4.1 seconds. YES!
So what was the solution to my problem? I went to bed.
And what does this have to do with your Product Backlog? Well, I want you and your team to go to sleep.
“Sprint Planning? Gaaaahhhh! No, thank you.”
Do you hate your Sprint Planning Meetings? Are they dull? Unproductive? Confusing? Pointless? Well, they don’t have to be.
When I work with a team that dreads their Sprint Planning Meetings (SPM), usually the #1 thing that I find is that they have no idea what they’re going to be working on. Now, you might be thinking “but isn’t that the whole point of the SPM that you figure out what you’re going to be doing?” Well, yes and no.
Yes, that is where you figure out what you’re doing in the sprint. But no, there’s no reason why you have to enter that meeting with zero idea what you’re going to be dealing with in that sprint. In fact, it’s probably a bad idea to have no idea.
If you have no idea about what’s coming up in the sprint, that means that the team probably doesn’t have a shared understanding of the product backlog. Thinking about what this means for the Sprint Planning Meeting, no shared understanding means that when you start discussing a Product Backlog Item (PBI) to tackle in the sprint, you really haven’t thought too much about it – or perhaps, at all. That Sprint Planning Meeting is going to be a chore. And fast-forwarding to the end of the sprint, the team is probably going to find that the plan they developed in the SPM was pretty wobbly and had a lot of unknown unknowns.
Making sure you have enough well-understood Product Backlog is essential for good, productive, non-awful Sprint Planning Meetings.
A Well-Understood Backlog
Ideally, you’ve got enough well-understood (aka. “ready”) product backlog so that you have a pretty solid understanding for what you’re going to do for the next 2 or 3 sprints.
Yes. You read that right. Two to three sprints worth of well-understood backlog. It’s the difference between driving down the highway looking a half-inch off of your hood versus looking a half-mile down the highway. If you’re looking out in the distance, there are a lot fewer scary surprises.
If you’re thinking that your backlog looks NOTHING like 2 or 3 sprints of understoodness, you’re not alone. Don’t beat yourself up about it. It’s just where you are today. But it doesn’t have to stay that way. You can fix it.
Ok. How?
Backlog Refinement
Backlog refinement is how we get to that well-understood backlog.
What is backlog refinement? You gather the team together and you discuss what’s coming up on the backlog. Ask questions. Do some estimating. Talk about interdependencies between the work that’s on the backlog. Talk about how you could break the work apart so that you can more easily deliver customer value. Talk about risks.
Basically, you talk what you’re going to do as a team and what you’ll need to know about your requirements (product backlog items) before you start working on them.
Kinda sounds like a low-stakes version of a Sprint Planning Meeting, huh? It sounds like it because it is.
A Sprint Planning Meeting typically has two parts: 1) what are we going to do and 2) how are we going to do it? If you’re doing backlog refinement, you’re pre-populating that “what are we going to do” part of the meeting.
My recommendation: do two 30-minute refinement meetings per week. Keep them focused. Keep them short. Discuss what you’re likely to do in the next sprint and the next next sprint. Ask questions like: * “how are we feeling about these next n PBIs?” * “what’s our likely approach on these PBIs?” * “Are they all small enough to make it all the way to Done in a sprint?” * “How will be we test them?” * “How will we deploy them?” * “What are the risks and unknowns for these PBIs?” * “What are the acceptance criteria?” * “Are there any new PBIs that we need to discuss?” * “Are the priorities for these PBIs still valid?” * “Are there any open questions about these PBIs?”
It’s a lot of work but think of how much easier and productive your Sprint Planning Meetings can be.
But why am I asking you to do two of these meetings each week?
Sleep on it
Your Product Backlog is made up of Product Backlog Items (PBIs). Those PBIs are the requirements that you’re thinking of delivering as part of your product.
Now, you might think that you talk about each PBI in a backlog refinement meeting one time and you’re done. You can do it that way. But I’d rather that you didn’t.
My advice for teams is to “refine” a PBI at least twice. Meaning, discuss it in at least two different backlog refinement meetings.
Why is this my advice? It’s because of sleep. Without having to do anything other than sleep, our brains grind on the problems and items that we run into during the day. What you’re hoping for is that you get one of those overnight epiphanies like I had with my code performance problem. More precisely – you’re hoping that everyone on your whole team has those epiphanies.
During the first refinement of a PBI, the team’s questions and thoughts on that PBI tend to be pretty superficial. During the second refinement of that PBI, if they’ve had a couple of days to mentally churn on it, they’ll understand the risks and interdependencies better. The team’s estimates are going to be better. They’re going to ask much, MUCH better questions.
If you’re the Product Owner, you definitely want that kind of deep questioning and feedback on your team’s PBIs. It helps to hone your understanding of your own PBIs. It helps the teams to find and hopefully propose interesting solutions to those inevitable sticky implementation problems.
It’s better to find those problems early. If there’s a big, sticky unknown that pops up during the Sprint Planning Meeting, it’s not always possible to address it. That might mean that you have to skip that PBI in that sprint or perhaps you end up creating a plan for implementing that PBI that isn’t based on solid reality.
The more that you can address those problems in backlog refinement meetings, the better off that you’ll be.
In Summary
The more well-understood backlog that you have, the better and smoother that your life will be. You should aim for at least 2 to 3 sprints worth of well-understood backlog. You’ll get that nice, clean, understood backlog by doing regular backlog refinement meetings. And try to sleep as much as you possibly can between refinement meetings. Sleep a lot in general. Sleeping helps your teams think.
Now go take a nap.
-Ben
– Do you want some help crafting and refining your Product Backlog? Need some Scrum coaching or training for your teams? Looking for assistance with Azure DevOps, GitHub, software architecture, or software testing? We can help. Drop us a line at info@benday.com or check out benday.com/training for more information.
