Backlog Grooming Bugs Me

Adopting new process language bothers me.  I was introduced to the Extreme Programming term “story” in 2000 and it wasn’t until 2005 that I stopped rolling my eyes when I heard the term and could actually begin to use it in sentences myself.

“Backlog grooming” isn’t a new term in the Scrum community, but it’s a term that still drives me up the wall.  Let me explain why.

Backlog grooming meeting as team torture

Years ago, I sat in on a painful meeting with a software development team I was just beginning to coach.  It was important that I learn the way they were working today, and respect the process choices they’d made so far.  It was my goal to observe and understand.

In this meeting, the whole team gathered in a conference room and projected a screen from a popular Agile management tool onto the wall.  The screen showed the backlog.  One by one the team went through backlog items, opened each item’s document containing a user story, and then read through the details with the Scrum Master facilitating and driving the keyboard.  Team members asked questions about the story.  The product owner did his best to answer questions.  Guided by the Scrum Master, the team tried to write acceptance criteria for each story in the document using a Behavior Driven Development style “given-when-then” format.

It sounds pretty straightforward.  At worst it sounds a bit boring. But it was worse, much worse.

It was clear by all the restless shifting in chairs and smartphone fiddling that no one wanted to be there.  The team didn’t seem to understand the product and  struggled to ask useful questions.  There were a couple developers that seemed to have an easy job participating and they seemed to delight in asking difficult questions the product owner couldn’t answer, or explaining to the product owner how the product “couldn’t do that.”  The more junior people seemed bewildered.  When they tried to ask questions they were often answered with eye-rolling and patronizing answers that made it clear to them that if they only knew the product or the domain, they’d have never asked in the first place.  The ScrumMaster tried to keep the team focused, but she had most of her attention on the tool trying to find stories and trying to get acceptance criteria keyed in.  She spent a fair bit of time correcting team member’s attempts at forming good acceptance criteria.

I sat at the back of the room watching, feeling the pain of the people in the room as the meeting dragged on for over two hours.  Toward the end, it was clear that people just wanted to escape.  When asked if they understood the story, or if the acceptance criteria made sense, they were quick to nod.  Their “yes’s” felt more like confessions extracted during torture than genuine agreement.

At the end when people filed out of the room I heard grumbling comments like, “How can we get any work done if we spend all our time in meetings?”

I asked someone, “How often do you do this?”

“Every week” he winced.

“What’s this meeting called?” I asked.

“It’s the backlog grooming meeting.  We have to do it in Scrum.”

It’s from this and many similar experiences with backlog grooming that I’ve come to develop a healthy disdain for the term.  Add to that the snickers I would get in response to the term when speaking to someone in the UK. Do a quick google search on the term “grooming” and you’ll see the kinds of things the term commonly refers to.  One common meaning is pretty disturbing, and it’s not “dog grooming.”

What I think Scrum creators really meant

I originally attended a Scrum class taught by Ken Schwaber in 2005.  When I dig back in my cobwebbed memory, I recall Ken saying that the Product Owner needs to keep the backlog groomed.  He explained that the backlog can turn into a mess of items expressed differently, overlapping each other, some no longer needed, and no longer sorted in priority order.  “Every sprint you’ll need to spend time keeping the backlog cleaned up,” is what I recall Ken saying.  This made sense to me.

On the other hand, the meeting I keep seeing that’s called a “backlog grooming” doesn’t make sense.  In fact, any Product Owner who participates routinely in this meeting knows the one thing they can’t do in the backlog grooming meeting is tidy up the backlog.  It had better be pretty well groomed before the grooming meeting or things will go badly.

As I read the current Scrum Guide,  I notice it doesn’t agree with what I recall hearing from Ken many years ago.  Possibly I’m imagining I heard it.  Today’s “Definitive Guide to Scrum” by Ken Schwaber and Jeff Sutherland does describe grooming as the process of, “Adding detail, estimates, and order to backlog items.” While doing that work makes sense, “grooming” may not be the word I’d choose.   The meeting I commonly see seems the poorest possible process solution for doing the work we need to do to get stories ready for upcoming sprints.

What went wrong

In trying to better understand the work successful product owners do to fill their role, I’ve spent a lot of time interviewing them.  I always ask product owners to “tell me about your worst day on the job.”  At least half the time I hear them describe an awful experience during a sprint planning meeting – that meeting where the whole team gets together to plan their work for the upcoming development time-box.  They describe the team asking them questions they weren’t prepared to answer.  They describe the team complaining that they didn’t have enough information to estimate work, to determine if they could or couldn’t get it done in the next couple weeks.  They describe the team and the company leadership blaming them for not doing enough work to prepare for the upcoming sprint.  Through hearing these stories, I feel a lot of their pain.

When I asked successful Product Owners what they did to feel ready for the upcoming sprint, almost all of them described lots of frequent conversation and collaboration with team members to talk through upcoming work before the Sprint.  Many of them described learning the hard way that on their own they could never come up with the right information to support a story.  They needed the discussion with team members to help them work through the details and to understand what options were feasible and what details were necessary to help team members proceed.

So, here’s where I believe the Scrum community went a little sideways.  This is the pretzel logic I think happened somewhere along the line:

• Sprint planning is painful when we’re not prepared
• Collaboration with team members before the sprint helps prepare
• Product Owners are supposed to keep the backlog groomed
• The whole team is responsible for the work done in the Sprint
• [Big idea] Let’s create a new whole team meeting called the “backlog grooming meeting” where the team and product owner collaborate to get ready for the upcoming sprint!

I’m hoping you have trouble with that logic, because I sure do.

What really works

The Product Owner does need to keep the backlog in good order and deliberately budget time every week to look over the backlog pull out things we no longer need, reorganize and rewrite items, and prioritize work so that we know what’s coming up at least in the next sprint and often, a couple sprints out.

I advocate widening product ownership to a team.  In working with my friend, Marty Cagan, we refer to this team as the “discovery team”.  It’s their job to discovery what should be built.  A balanced discovery team includes someone who understand the business concerns that motivate building software, users and their concerns and how they’ll use the software, and someone who understands the engineering concerns and can help identify what’s feasible to build.  It’s from this intersection of valuable, usable, and feasible that good products spring forth.  A single Product Owner may lead the team, but it’s still a team.

The most successful organizations have balanced product teams that meet routinely, usually weekly, to review and reorganize the backlog, and plan the discovery work they need to do to get ready .

Product Owners need frequent collaboration with team members to help everyone think through and understand what we can build.

I remember the good old days in software development that when we were faced with a challenge, we rushed to a whiteboard to talk things through.  A few of us would have often loud discussions, drew lots of pictures, argued a bit, shared ideas, and eventually we’d agree on what we could do.  Often we’d end up realizing we might need to prototype something or talk to users to learn something we didn’t understand.  This worked well and it still does.

The best product owners have routine story discussions with team members to talk through options and details for the work they’re doing.

Good Product Owners keep these discussions small and include the people passionate about the work and helpful in thinking through the details.  They know we’re hear to learn, to consider options, and make decisions.   They know that we’re not meeting to communicate requirements, but that together we’ll make decisions about what to build that best solves problems.  Ultimately, participants drive to some agreement on exactly what we’ll build.  They’ll answer the question, “What would we check to confirm it’s complete?”  The answer to that question is acceptance criteria or story tests.

One of the better product Ownership groups I worked with holds Story Workshops at least once a week, sometimes twice.  They post on a visible calendar when the workshops will be and write in the names of the stories they’ll be workshopping in the next session.  The stories to be discussed in the next meting look a little like “daily specials” at a restaurant.  Team members “opt-in.”  They decide if they want to attend or not.  If a workshop starts and they’re missing someone important, like a tester who’ll be responsible for verifying the work is done right, then the Scrum Master rushes out to see if they can round someone up to participate.  But, for the group I’m thinking of, most of the time the right people do opt-in.  Discussions are animated and fun.  Team members look forward to this opportunity to collaborate.

Later, at Sprint Planning, team members are familiar with the stories.  They helped decide on them.  They helped author the acceptance criteria, and are quick to help explain details to other team members who didn’t help workshop the story.  And, when “that guy” – you know the one – that guy who delights in poking holes in everything pipes in, team members fight back.  I’ve heard team members ask, “Hey – where were you when we workshopped this over the last couple weeks?!  It would have been good to hear this then.  Right now you’re just slowing us down.”

Use product team planning and story workshops to prepare

The combination of product team planning and story workshopping works.

Yes, keep the backlog groomed, but don’t make the whole team do it.  Do a bit of it on your own, and lots of it with your closest collaborators – a balanced product discovery team.

Use product team planning meetings to discuss how the release is progressing and to choose stories for upcoming Sprints.  Use the time together to identify the work you’ll need to do to get stories ready for the upcoming Sprint.

Use routine workshops with team members to work through the story details.  Keep these workshops small and productive.  Don’t exclude those who want to be there. However, don’t make people attend who don’t have a desire to contribute.

Pay attention to what happens during sprint planning, everyday during the sprint, and later at a sprint review.  You’ll get a feel for the kinds of things you need to be discussing during workshops to help things go smoother.

Stuff to download:

Quick reference postcards for Product Team Planning, and Story Workshops (Word Doc)