Grooming a product backlog

How many times do you or your team work with the product owner to groom the backlog? Once or twice a sprint? Once a month? Less? How about trying to do it every other day, or even every day?

Grooming the product backlog is one of the most important things you can do in scrum (besides following the rules and um, delivering). It helps you maintain a healthy outlook on what you’ve got to do, it helps you recognise and deal with dependencies and blockers earlier and it goes a long way toward release planning and estimating a project delivery date (or date range, more likely).

Also, if you groom the backlog daily, it’ll take much less time and be a much less arduous task. I’ve done both. Sitting with the product owner once a week to groom a backlog of many, many stories is a pain in the arse. The most appropriate time is just after the stand-up. You’re all standing around the sprint/product backlog, so take the time to ask for a couple of volunteers to spend 15 minutes examining some stories, grab the product owner as well. I always suggest that anything bigger than a five pointer is probably a good candidate for breaking down a bit further or defining acceptance criteria and anything bigger than a 13 should definitely be broken down further.

Take a big or ill-defined story and ask, can this be broken down? Can we break this into any smaller parts that offer business value? If so, then great, break it up there and then, if not, then ask if it can be broken into smaller parts that don’t provide business value? Sometimes, this is a worthwhile questions as, when you break a story into smaller, non-valuable parts, inherent value sometimes bubbles to the surface, taken out of context, the team might spot a way that smaller stories that don’t deliver value, might actually do so after all.

Then ask the team if the acceptance criteria is accurate enough, does it, in their opinion, describe the “done” state of the story? Obviously, the only party who can actually say when it’s really “done done” is the business, but your team will always have a good idea of what “done” is to them and the product owner should be able to offer more information on what the “done” state is.

Finally, see if you can ascertain some kind of rough priority order, this is especially relevant for technical stories that may not provide value for the business at large, but will often support other stories that do provide value and you should always try and pay off your technical debt wherever possible.

So, if you groom the backlog with the product owner and various members of your team more regularly than you do now, when you get to sprint planning, it’ll be a breeze. You’ll spend much less time discussing what the stories mean than the actual tasks needed to complete them. You’ll know exactly which supporting technical stories you may need and, if you’ve been aggressive at breaking down stories to two, three of five story points, you’ll be able to be fairly accurate with your commitment.

And really, that’s what it’s all about, being slightly more accurate, so the confidence of your team is high that you can complete what you’ve committed too. Your team will love you for making sprint planning less like pulling teeth and your product owner will love you for delivering what you’ve committed to.

Win-Win as they say.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s