Backlog Grooming

Backlog grooming is a place for a team to discuss each individual user story in a greater detail before taking it for development. It is absolutely necessary to involve product owner at this stage to ensure the team can raise and address questions as part of the process.

Backlog grooming is a very important part of the product development process that aligns the team's execution. It is an activity directed to remove unknowns and reduce risk for delivery of the solution.

Before Backlog Grooming meeting

1. Product Manager shares list of tickets to be groomed a day or two before the actual Backlog grooming meeting.

   This allows dev team to research tickets and think about problem and potential solutions before the Backlog grooming call.

2. Capture all of the relevant technical details of proposed solution in a ticket itself, under "Tech Notes" section.

On the Backlog Grooming meeting

1. During Backlog grooming call where you as a team go over list of tickets where each engineer that was researching their specific ticket, presents proposed solution to the whole team.
2. Next up, team estimates the ticket and marks it ready for dev.

Make sure to keep the pace, keeping in mind that you need to go thru entire list of planned tickets to be groomed. If you see one specific ticket as a point of contention within the team, do not spend more time than necessary discussing it on a call, take it for additional research offline.

When starting with new team or new project, have as many Backlog groomings per sprint as necessary in order to create groomed and prioritized product backlog.

Over time you are likely to converge to 1 or 2 groomings per sprint.

Activities

For each user story that is discussed on backlog grooming there are usually few activities that take place:

1. Product owner presents user story to the team for discussion:

   This gives a chance for every team member to ask a question or raise a suggestion.

2. Ensure Acceptance Criteria is complete and team members have no questions:

   This is a good place to ensure that Acceptance Criteria is complete to satistfy definition of ready for dev. Here are some of the items:

   • Do we have design attached to the ticket?
   • For literals that need to be translated - do we have translations?
   • Do we have specification example?

3. Team decides if user story need to be split in multiple tasks:

   To decide if you want to break it down, try answering some of the questions here:

   • Can the work be done in parallel?
   • Are there tasks that belong to different workstreams?

4. Estimation:

Estimate work required to complete the user story (or a task). It's ok to re-estimate at the Sprint Planning stage, so don't be affraid that you may not have all the details at hand right now.

Technical Notes

One of the things we adopted over years of experience working with different scrum teams as a best practice is writing Tech Notes.

The idea is that in addition to discussing "What" needs to be done we also discuss and document "How". Developers usually assign stories for grooming 1 or 2 days before the call, so they can familliarize themselves and ask quality questions or propose quality solution at the time of grooming.

Key to success

Leave no decisions to be made by developer when they pick up user story for development

For user stories when it's impossible to know the approach or answer before you actually start working on a problem hands-on, we usually create an "Investigation" user story worth 1 or 2 points depending on a scope of work. Outcome of this user story is usually a documented implementation proposal that will be used as a tech note for the actual user story in question.