· 7 min read ·
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.
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.
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:
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.
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
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:
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:
After the Backlog Grooming Meeting
Once the backlog meeting is over and you are at your desk make sure you do the following soon:
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.
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:
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:
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.