The Backlog Grooming Session

The Backlog Grooming Session

We have talked about Product Backlog in depth in a previous blog. Here we are going to focus on one of the key meetings that you will be responsible for as a product manager. This is the Product Backlog Grooming Meeting. It is an opportunity for product managers to get together with the development team and go over upcoming projects in detail. It should not be confused with the Product or Project Kickoff meeting. The backlog meeting is more focussed in which specific epics and user stories are discussed. Questions are answered or marked for followup at a later date.

What is the Backlog Grooming Session

Product Backlog session is an assembly of different people working together to build and release a product. It comprises primarily of members from product and engineering teams. Sometimes design and data analytics folks attend as well.

Why is the Backlog Grooming Meeting Important

Tackling large projects can be a daunting task even for seasoned managers. The idea of incremental and measurable releases enables large projects to be tackled in an effective manner. Product Managers break down projects into smaller epics, user stories and tasks. They provide a great level of detail in each story. But expecting someone to just pick up the story and run with it is wishful thinking. I’m not saying that it’s not possible. But it would take for teams to be working together for a very long time to be able to reach that level of understanding. In my entire working career I have been able to do that with one team!!! And it was amazing. For every other team, backlog meetings were critical.

Before writing up the user stories for an upcoming release a product manager talks to a lot of customers and stakeholders. In those meetings they go over “What” the user needs. The product manager then converts the “What” into stories that can be worked on by the development team. Few important points to note here:

1.There is a lot of contextual information that can’t be put down in the user stories
2.It is common to miss out on edge cases that are surfaced in these meetings
3.Technical implementation details often impact the scope of the user stories
4.The details in the user stories might not be enough

Hence backlog meetings are an important part of any development process or framework. The word “backlog” is taken from Scrum. In Kanban its equivalent is called a “replenishment” meeting. As in when the backlog is running low on user stories and you need to “replenish” it.

What happens in a Backlog Meeting

The backlog meeting can be scheduled at regular intervals or can be done adhoc as and when needed. Members of the development, design and product teams participate in the backlog meeting. It is common for the entire development team for the particular product to join the backlog meeting. Designers might join on a need basis. In my opinion  backlog meetings run smoothly if the product manager and the engineering manager run it together.

Before the Backlog Grooming Meeting

There are a number of things you can do before the meeting to make it more productive. Make sure to send the meeting invite much ahead of time. In most cases you will end up scheduling a recurring meeting otherwise it might get challenging to find a common availability for everyone to meet

1.The meeting invite should specify the goals of the meeting and expectations from participants
2.Ideally a day before the meeting you should update the meeting invite with links to user stories that you’d like to discuss with the team. You can also add links to contextual information that might be useful for the team.
3.Meetings rooms that are large enough for the team should be blocked. Trust me this can often times become a big issue for you
4.If participants are joining online then the online meeting links should be added to the meeting
5.The meeting room should have a working projector or screen for everyone to look at.
6.Make sure that you are able to connect to the projector and share your screen for the virtual participants. I can’t tell you how many times I’ve had the entire team sitting in the room and not being able to get going because of “technical” reasons 🤪 .
7.Make sure you choose a day or time where everyone is able to focus on the task at hand. For example, 9am on a Monday might not be a good time for most teams.

The points discussed above come under basic hygiene that shouldn’t be limited to just backlog meetings. You should do this for every meeting you organize.

During the Backlog Grooming Meeting

Ok so you have done the part described above and it’s time for you to run your backlog meeting. How should you go about it? Here are some pointers:

1.Start on a light note. A joke is always welcome. But take a call depending on the atmosphere in the room
2.Don’t dive into the user stories straight away
3.Talk for a few minutes about “what” we want to do and “why” it is important. When people know why they are doing what they are doing they also do their best work.
4.An engineering team that has the right business context build better products
5.The flow of the users stories should match how users will use the product
6.Talk through each user story. Make sure that you identify the target user persona it is for and how they will benefit from this work.
7.Go over EVERY acceptance criteria
8.After the end of each user story ask the team if they have any questions
9.Make changes right there in each user story so that everyone in the metting can look at what you typed out. Typing out when the entire team is looking can be daunting for some (thats when we make all the typos don’t we 🤪 ) but this is essential! Taking notes on the shared screen gives opportunity for everyone to reflect on it and give their own inputs. Also, it saves time for you post the meeting.
10.Add comments - keep a tab open to record notes, comments, decisions.

Now comes the fun part! Estimating the user stories. Lot’s of different ways to do it. Some teams play points poker, others put in actual human hours required to complete it. You will always be surprised with what comes out in terms of estimation 🤔 .

If the final estimate on a story is much higher than what you had expected then you will have to either:

1.Cut the scope of the user story so that the estimate comes down to an acceptable range
2.Make some parts of the user story “stretch” requirements. These are things that the development team should only do if there is some time left after completing the important parts of the user story
3.Live with the estimate and work on managing the upstream work for the release accordingly.

After the Backlog Grooming Meeting

Once the backlog meeting is over and you are at your desk make sure you do the following soon:

1.Send any action items discussed in the meeting that need to be worked on. Include due dates if available
2.Compile a list of important decisions that were taken in the meeting and the reasoning behind it.

These notes don’t need to be as long as an essay. Short bullet points are enough. You don’t want to be sitting in the next grooming meeting and wondering why you did what you did in the earlier meetings. This will help you avoid such a situation from happening.

Challenges with Backlog Grooming Meetings

There is a purpose behind backlog meetings. It is to get everyone who is involved in the part of the project that’s up next to get together and go over the specifications. By doing this you avoid having multiple meetings and discussing the same questions again and again with different sets of people. But just like any other meeting you can easily run into challenges with this as well. It is very easy for this discussion to get sidetracked. Let’s hear some of the common themes you are bound to hear in backlog meetings:

Is this really what we should focus on?

People will ask you why this versus building something else. By doing a product kickoff meeting you can explain the data and reasoning behind the area of focus for the product. You will run into this question very often even after you have done the product kickoff. People have short memories and a ton of things to do. So they might and they will forget the kickoff meeting from a few months ago 🤣 . Your job is to make the kickoff presentation available to everyone so that you can point them to the right resource when such questions arise.

Have you considered the following scenario?

When you are going over the user stories you are bound to uncover scenarios you have not thought off. And it’s OK!! One of the goals of a backlog meeting is to do exactly that. The scenario might be the following:

1.It’s something important that you have missed. In this case make a note of it and bring it back to the team in the next meeting.
2.An edge case that is not worth investing into. In this case document that the team discussed it and decided it was not a priority

Why can’t we add an “x” feature?

It is easy for the backlog meeting to become an ideation session and it is the product manager’s job to keep everyone on track. Questions will come up as to why can’t we add a particular feature to a release. The feature might fall into the following buckets:

1.Needs to be done: The features was missed and needs to be prioritized
2.Nice to have: It’s a good idea that should be explored for a future release
3.Won’t do: It does not make sense to work on this feature in the short term

Conclusion

I have found backlog meetings to be extremely helpful for a smooth development and release cycle. It get everyone on the same page on what is expected at the end of each iteration. The times when I skipped the backlog step and put the user stories directly into development I have always run into issues 😭 . Backlog meetings can sometimes seem like a huge drain on resources because of it’s frequency and the large number of people involved. But it saves you a lot of time and effort.

Let us know how you run your backlog meetings and what you have learnt from them.


You may also like