Tips on How to Improve Backlog Grooming Meetings
6 October, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.
Chief Technology and Product Officer at Hive Learning
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.
Google Cloud Practice lead at Contino
When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..
VP - Engineering at ITILITE Technologies
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.
Director of Engineering at Inspire Energy