Tips on How to Improve Backlog Grooming Meetings

Problem

When I joined a team, our grooming meetings were not going as planned. We were discussing 2 tickets because several opposing questions were being asked, or the clarity requirement was not present. Only a few people had expertise in those areas, and only they would be talking in the meetings, while others remained silent only to listen. It became more like a classroom setting than a discussion session. Some detailing could have been done ahead of time, while the meeting time could be used for something more productive like: this is what we need to do and story points them out based on the complexity. Having requirement clarity discussions to be done was a waste of time. In the end, there was a lot of confusion on what needed to be done and when the release was.

Actions taken

Around the core group meetings that we had, every senior engineer within the team had to take the lead. They would take the responsibility of understanding the requirements with the product lead, groom the story outside, and then bring it to the main room to articulate the stories better and enable the team members to break them down into smaller pieces.

We introduced release-when-ready strategies, whereby at the end of every sprint, every story should be a deployable item and further move to production. We had to work on some background stories, such as having better test suites and introducing feature flags into the system. Even if a feature was partially completed, they could disable it by turning off the flag.

Because earlier, towards the time of release, all the tickets were getting merged into the release branch, there was a lot of release conflict. It slowed down our processes and created many problems with respect to the release. To minimize that, we started pushing our people to ‘release when ready.’ We changed the workflow of our Jira, whereby if anyone were closing a story, it would automatically mean that the code is already pushed to production.

Such processes helped a lot because people started breaking down the stories, and everything moved to production a little faster. However, in terms of our code reviews, which were getting delayed, we introduced another process, where a person could pull data, and right before the standup on Slack, they could send out the number of pending reviews. This increased accountability amongst others because they could look at the Slack message which acted as a reminder for them.

Lessons learned

• Make sure that you sync up on the important details that might be causing the bottlenecks at your company standups. A data-driven standup would help the team bring better results.
• Do not assume that your team members are not going in the right direction. In order to make sure that they are on the right track, try to bring in as many as data-driven discussions that would help.
• The problem could be somewhere, whilst the solution could be something completely different from what you thought. Dig deeper to try and understand the root cause of the problem before bringing in solutions.