These are my services: Groomings

This is a part of a series where I attempt to explain how I see my role as a Scrum Master. Today, we’re going to walk through my brain during a backlog grooming session.

Mission

The only mission of each grooming session I have is to better understand the work we currently have in the horizon. That’s it. Everything else is discussed outside of the grooming.

No overall structure

I don’t follow one strict structure or format in the groomings I’m involved in. Considering it’s a creative process of discovery and different teams are creative in different ways, there’s not one mold that works for any one team. In fact, one team rarely works the same way in all of their groomings. You can’t standardize creativity. And that’s okay.

A grooming session is all about the team and the Product Owner — they’re the stars of this show. This is the dedicated time for them to talk with each other with the topic “the product’s future”. My primary task is to make sure that we get the most of the time that we’ve carved out of the day of this very busy crowd.

Sometimes the session is about the PO presenting something completely new, which turns this meeting into a presentation, with Q&A at the end. If the PO has nothing completely new to present, we start agreeing on business level details, something closer to user stories. Usually one follows the other.

This is the closest to a structure I can think of:

• Ask everyone in the room: “Why are we sitting in this room?” Or more directly: “What do we need to get done during these x minutes?” I might write the answer down on a whiteboard, to remind people of what they wanted to concentrate on.
• If the room doesn’t agree on one answer after a bit of discussion, it’s not a grooming anymore, and that needs to be made clear to everyone in the room.
• If the room doesn’t come up with anything at all, it sounds like someone outside of the team has decided that groomings are a good idea. The idea needs to come from the team. A team cannot be self-organizing if it doesn’t organize its own meetings. This is a dangerous sign.
• Then I mostly shut up and and listen to the conversation.

You might note that I don’t dictate any topics. I even try not to suggest anything. I like to trust the team to talk about relevant things before they need the information. If they fail to do that, they usually end up realizing their mistake pretty independently. It’s important for the teams to allow for these kinds of mistakes and thus learning from them. I try to let them do them as often as possible, as long as failing doesn’t lead to anything bad that actually matters.

What I listen for

Is the discussion affecting everyone present, and is everyone present that the discussion affects? Sometimes the entire team doesn’t have to be in the room listening to the subject. That’s okay, they can (well, should) leave the meeting. Sometimes the discussion needs people outside of the meeting. That’s also okay, let’s fetch them into the discussion, or save the discussion for when we can get a hold of them.

Is the discussion on a level that is relevant to everyone here? The developers are sometimes quite eager to start talking about the implementation of a feature mentioned by the PO. This isn’t the time nor the place, the PO isn’t needed here for that. Yet, if technical talk is the most important thing we can do at this point, I welcome the PO to either sit in or leave to do something else.

Is someone mixing up technical requirements with business requirements? Then there’s the issue of implementation details disguised as business requirements. This can be either PO wanting something to be implemented a certain way (“There should be a save button” when the only requirement is persistence, one way or another), or the team asking how the PO wants something to be implemented (“Should we use SQL or NoSQL?” when the only requirement is persistence, one way or another). Sometimes this is level of discussion warranted, but most often the typical PO shouldn’t worry about it. The development team should make their own decisions and stand by them.

Is everyone getting their voice heard? As important it is to have everyone involved in the room, it’s equally important to have everyone heard. Everyone has something to bring to the table, and usually the silent ones have exceptionally valuable insight. I like to throw in the occasional “Do you, Silent Bob, have anything you want to add?” or “What do you think about all this, Bob?”

How many are listening vs participating? If there’s an opportunity to split the team into smaller groups (2–4 persons each) to talk about separate things, I try to take it. This helps everyone to be productive at the same time, since there can be more active discussions at the same time. Of course, not everyone can listen in on all the discussions, but this has not been an issue for me. This part is more about gathering understanding. The distilled knowledge is easier to share, e.g. at the end of the session.

Are we still grooming? It might be surprising, but I don’t care too much about this. As long as everyone is engaged and the discussion is relevant for everyone, I see no reason to interrupt anything. Either they’re talking about something else relevant to their work, which is fine. If they’re not, then I don’t see any harm in some friendly banter between the business and technical people.

Am I talking too much? If I find myself pushing the meeting along and it still isn’t taking off, it means that it’s the wrong meeting at the wrong time (maybe with the wrong people). At this point, a genuine “is something bothering you?” aimed at the team in general goes a long way. If an impromptu free-form retrospective starts to take place, I’ll take it as far (and long) as the team wants it. But if that doesn’t bite either, then ending the meeting is probably my best bet.

Remember to cherish everyone’s flow

I’m very careful of letting everyone have their uninterrupted work time. All meetings (groomings included) are best scheduled by aligning them against natural context switches: Start of the day, end of the day, just before lunch and right after lunch are my favorites. One further candidate is right against some other meeting, but I try to avoid having many meetings per day anyways. I’d first consider another day before going here, if at all possible.

I currently have recurring groomings, but I’m toying with the thought of having them whenever needed instead. I can see both having their pros and cons. Scheduled events make people explicitly switch context from programming and makes sure that everything is understood. But this leads to more interruptions. Mature teams probably get away with less unscheduled events. This assumes that they actually do raise the issue whenever there’s a need to talk more about something.