Improving Sprint Success: The Technical Grooming Meeting

I have found success recently to improving the team’s success by having a one hour meeting per week: Technical Grooming.

I go over the whys, whats, and hows to have a successful technical grooming meeting to improve the team’s output.

If you are a technical leader that is responsible for a team’s performance, this will give you another tool to help improve the team’s performance.

This article will take you about four minutes to read.

Introduction

In our workflow, we have grooming sessions, where product introduces the story to the team for the first time, explaining why the work is important to do and what they expect the result should be. Sound familiar?

I have another meeting, called: technical grooming, with just with my team focusing on technical implementation after the story introduction to focus on the technical aspects.

Why more meetings?

A key feedback I have received from the team is they feel too much pressure in grooming sessions to “point a story”. (Trust me, I was guilty of this on both sides as well.)

I find that pointing a story the first time one sees it is a lot of pressure, even when structured properly. Thoughts that come to my head whenever I see a new story:

What do we have already that does this? Anything similar? Can that help? How? Is another part of the system doing this already? Is there an external library? Do I have to write it from scratch?

Taking another meeting to just discuss the story on a technical level (and clarify those questions above) allows the team have a different understanding of the story.

By having a dedicated meeting to resolve those questions, the team would be more confident in delivering the story within a sprint and any points assigned.

What results?

For technical grooming - the attendees are only the engineering team, focusing on technical implementation.

What I expect from the meeting:

• Basic discovery done - an understanding of the current state.
  • Record any questions for another team in the story during this process.
• Have at least one idea on path forward to desired state.
• If points were not assigned in grooming, decide on points for the story that everyone on the team is confident in, no matter who takes the story

Ideally, apply all three of these activities to every story reviewed in the grooming meeting with the same pace (i.e. grooming meeting covers five stories, technical grooming covers five stories too.)

How to get results?

With the why and what explained in grooming, technical grooming only focuses on the how parts of story.

Every story is different, some of the things I always do:

• Reviewing existing code as it pertains to the story.
• How I would approach solving the story.
• Let team discuss implementation trade-offs when there’s more than one obvious way to solve the story.
• Review other resources to use to solve the story.
• Let previous implementer walk through their solution as a refresher for the team.

Each of these add value to the team. As much as would love to just dictate “how” to run a technical grooming meeting, it’s still a work in progress for me and new learnings.

Current Learnings

This has been a good meeting to have and the benefits are solid.

Originally, technical grooming was about getting team members up to speed on the story and so stories get done faster. The goal: reducing “discovery” time and increasing “implementation” time.

Technical grooming has helped tremendously in this.

Additional Benefits

Over the longer term, I have found more benefits of technical grooming:

• Everyone in the team knows how to start a story, even less tenured team members or people who were not “original authors” of the first solution.
• Pull requests never have comment: “could reusing another part of the codebase solve the same problem with a tweak?”
  • For me, this is one of the worst comments to get, especially near the end of a sprint.
• Group discussions on trade-offs allows learning for everyone.
• Safe space for technical discussion - bringing up good/bad/crazy ideas.

Current Feedback

There are areas which I have received feedback and/or noticed we can improve on:

• Product feedback has been positive when engineers have another meeting just to review technical details for stories. They do get concerned when the team doesn’t point after three grooming meetings.
  • Idea: Have stories technically reviewed and pointed within seeing it three times (grooming, technical grooming, grooming)
• As this is another meeting, this takes away one hour times Y team members. For a one hour meeting, it would be 2.5% of each member of the team’s time. Time the team would be spending on… the current sprint!
  • Maintain timely meetings: one hour means one hour! For sprints with lighter weeks, there can be additional technical grooming meetings to cover future stories or more technical discussions.
• As there’s more to technical grooming than just reviewing the “why” and “what” of a story, the team can spend more time discussing a story technically than in actual grooming. Technical trade-offs discussions can go / have gone on tangents, eating up valuable meeting time.
  • Idea: Have another meeting for discussing tangents that come up and/or group sharing of technical information

Just part of the continuous improvement process!

Conclusion

This is a work in progress to improve our sprint workflow. I have enjoyed having this additional meeting as it:

• Reduce discovery time and increase implementation time in a sprint.
• Gives engineering team space to technically review a story.
• Presents opportunity for technical learning in a group setting.

If you have tips or advice to improve sprints, please contact me. I am always looking to improve!