Backlog grooming sessions help build a strong development team because they foster and force communication between team members about how they design, code and test an application.
The backlog grooming meeting is where a team attempts to fully understand the requested business requirements. This session is when the team discovers how it will design a deliverable product that functions as expected and works within the existing code architecture. This meeting is also the space where the QA professionals/testers receive the background design information and expected results from the other members of the project.
Let's review the important elements of the backlog grooming process, and how it can improve the productivity of a team and the quality of the software they produce.
What effective grooming sessions entail
When the team comes together for a backlog grooming session, the main goal is to gain a common understanding of a user story or user stories. Based on that shared understanding, the team then discusses potential designs before developers write any lines of code. After the meeting, it's important that there are still open lines of communication between all team members to maintain productivity and explain any changes as they come.
Think of backlog grooming meetings as prepaying for something instead of paying after the fact. For example, if a team comes to a shared understanding before coding starts, it limits the chance of design and function questions and interruptions after coding has begun. The review is effective only when team members participate in the discussion, ask questions and debate the value of different ideas or designs.
The number of user stories a team grooms is an important consideration. Teams don't want to meet constantly to evaluate these issues. Instead, keep your backlog grooming sessions to an hour in length and cover enough stories to keep the team occupied for a couple sprints.
How backlog grooming should be done
When a team generates vastly different story point estimates for a user story during the grooming session, it's clear that some team members aren't on the same page. For example, if Developer A assigns the story three points, Developer B says eight points, Developer C comes in with five and QA gives it 13, the story obviously requires clarification. It's not that everyone needs to agree on the point value exactly, but the team should be in the same ballpark of the business need and expected functionality.
In backlog grooming, treat the user story as a business case with acceptance criteria and nothing more. Discuss the details during grooming to dig into how the feature will function. By doing so during backlog grooming, you'll find out if the team has a shared understanding of the result or if there are missing requirements -- or missing stories needed to create the feature. It's better to find out early if a story needs additional supporting stories, tasks or research before the development team can successfully implement it.
Focus a backlog grooming session on clarity, said Timothy Hatcher, a senior software engineer at Apple. If the team does not understand the request in the same way, developers will not code the software correctly. According to Hatcher, it may be best to break down highly complex stories -- with integrated features or back-end requirements -- into smaller stories where the team can discuss and review design and integration points to figure out the optimal approach. Integrated user stories that are highly complex can throw the team and sprint out of orbit. Hatcher added it's in your best interests to groom user stories to ensure the plan of attack is clear to all team members. Otherwise, what you'll end up with is a story that isn't quite right and generates additional work to correct.
Why backlog grooming is important
Another benefit of backlog grooming is knowing the team scope of work. The fewer surprises thrown into a sprint, the more likely it is the team will produce quality code. The better the development team communicates, discusses and reaches decisions, the stronger the team will become.
A strong team produces more work, and work that provides a higher degree of quality. Backlog grooming sessions help build that necessary team camaraderie in a meaningful way.
It's tempting to skip backlog grooming and proceed directly to sprint planning, coding and then testing. But without it, teams can lose valuable time by going back and forth between team members. For example, developers won't have the information they need to code, and QA won't have the functional details they need to prove that acceptance criteria are met.
As a result of this confusion, teams will either go on with their own understanding of the user story or they'll constantly ask for clarity from the product team. Ultimately though, it's beneficial to discuss the user stories together rather than in piecemeal conversations. And it's more efficient for a team to take the time to talk via a backlog grooming session than go around in circles trying to get on the same page.