Enter your email and we will send you a password immediately
If Alex has provided you with a password, enter it here
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.
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.
Capture all of the relevant technical details of proposed solution in a ticket itself, under "Tech Notes" section.
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.
For each user story that is discussed on backlog grooming there are usually few activities that take place:
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.
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:
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:
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.
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.
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.