Backlog Grooming Guide – Corporate Hellion

This is part of a short series on scrum ceremonies and I’ve done some short pieces for each one. Here’s the complete list:

In order to have a usable backlog, we need input from lots of different sources. The goal of backlog grooming is to have your development team answer the following questions for each item on the backlog:

Does this ticket have enough information for me to be able to work on it (see Definition of Ready)?
What is a rough estimate on the amount of effort I’d need to put into this ticket to complete it (see Scoring)?

Attendees

The following attendees are mandatory so no information or perspective is missed:

Product Owner (to explain the ask and give insight into business value and priority)
Scrum Master (to audit that tickets meet definition of ready as we go)
Developers (to provide an estimation of effort for each ticket and audit for Readiness)
QA (these guys provide estimates and help us audit for Readiness)

Unlike some of the other Agile ceremonies, it is critical that your Product Owner is present during backlog grooming. This is because they need to be available if the requirements of a ticket are not immediately apparent while trying to score each item.

Tools

Tools for backlog grooming depend on your ticketing system (Trello, Jira, Microsoft Project, etc). Your Product Owner may sort tickets in the general product backlog, or opt to go sprint-by-sprint or project-by-project using a list of their choosing.

Output/Documentation

Only two key outputs here:

Groomed, pointed tickets that are ready to be worked on
Action items for the Product Owner if a ticket needs more information/detailed acceptance criteria/screenshots/designs/etc.

How to: Backlog Grooming

1. Opening the session

One of the most important roles as a Scrum Master is to keep your team grounded. A good way to accomplish this is to open the backlog grooming session by confirming with your team, “what do we want to accomplish with this project?”. By keeping the overall goal (or goals) in mind, you and your team will be able to prioritise the backlog on even footing.

2. Assign roles for the meeting

For particularly long or complicated project backlogs, it helps to assign roles for the meeting. Choose a person to be the scribe (the person who edits and updates tickets) while you read each backlog item to the rest of the group.

3. Add new items to the backlog

Spend five minutes with your team doing a quick once-over of the backlog and adding anything that may be missing. If you can’t come up with anything in those five minutes, it probably isn’t important enough to add to the next sprint.

4. Audit the story

This is where our scribe comes into play. Starting from the top and working your way down, open up each ticket and check that it has the following:

A user story: “As a ______, I need to _____ so I can _____.”
Priority: is this a high, medium, or low priority? If there’s disagreement over what band the ticket falls into, talk about it but remember the Product Owner has the final say over a ticket’s priority.
Dependencies: If there are dependencies on other tickets, list them here.
Acceptance criteria: Also known as requirements. This may include screenshots, wireframes and other reference materials.
- Actual static images are preferred to be attached to the ticket rather than a link, to avoid designs being changed during development.
Scope: Affected areas of the product or functionality.
- If the scope of a ticket changes functionality, a new ticket should be created.
Estimate of Effort: A Fibonacci score from 1 to 13 based on these parameters.

5. Confirm relative priority with Product

Keyword: relative! That means each ticket is judged according to how urgent it is in relation to other tickets.

If you’re using Jira and searching using a filter, the results can be sorted into larger priority bands (Critical, Major, Normal, etc). The default priority in your standard Jira project is Normal, so it’s good to confirm the priority of any Normal priority tickets with your Product Owner.

For particularly large backlogs, it may be unreasonable to get through grooming and sorting every ticket. If that’s the case, just focus on getting the highest priority items sorted for this session – chances are you won’t get to the lower priority stuff in the next sprint anyway, and by the time the next sprint comes around the backlog will be due for another grooming session anyway.

6. Final pass

Make one final pass of the backlog, auditing for readiness and giving the team one last chance to raise any objections.

7. All done!

Bask in the glory of your neat, organised backlog and take comfort in the fact that this will make sprint planning a billion times easier.

Key Takeaways

It is ideal to plan at least one sprint ahead, but no more than three. If your Product team is planning more than three sprints of content ahead, that limits the degree of flexibility the team has with response to product feedback.
No tickets go into a sprint that aren’t ready. That means you need to heavily emphisise to Product that the tickets they write need to meet the Definition of Ready to be included in the next sprint.
Tickets must be scored. If QA is part of your development team, that means tickets must be scored by Dev and QA.
- Product should never be scoring a ticket because they are not the ones that will be working on it.
Tickets don’t have to be assigned during backlog grooming.
- In fact, aside from one or two per team member to get started, don’t assign most tickets. If someone finishes a ticket and wants to grab a new one from the backlog, it’s easier to do that when it’s not assigned to somebody else.

The aim of a grooming session is to flesh out the ticket to a point where:

The ticket is understood by developers, QA and product and all are on the same page as to what the ticket describes
All major questions have been asked and answered or are under research
Each ticket has a score estimate to the ticket (level of effort)
Any dependencies which the ticket creates or is dependent on have been identified.