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.

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.

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.