The 2023 Guide To Grooming in Agile

Grooming is taking your product’s to-do list of work and transforming it into a product backlog.

If you’d like to learn how to groom or refine your backlog so you’re ready for your Sprint, just keep reading.

Discover the little know secrets to success as a Scrum Master with our complete Scrum Master guide, or get trained with our Registered Scrum Master (RSM) training.

Let’s start with a quick working definition.

Grooming, also known as refinement in Scrum, is taking notional work and clarifying the scope, testing, and effort estimates associated with that work until it is ready to turn over to the developers to start.

When you are grooming your backlog your team starts with a list of roughly defined work and ends with neatly defined units of well understood work. These neatly defined units of work have been “groomed”.

Once this critical step is complete, your developers are ready to get to work.

The definition above helps but please note it contains three critical components

1. Well understood scope of work
2. Clear testing criteria to assure the quality of the work
3. Estimation of the effort to complete the work within the timebox

Guide To Grooming Your Backlog

1. Gather the entire team
2. Have the Product Owner explain the product vision and goal
3. Have the Product Owner explain the goal of this grooming session
4. Allow everyone a few minutes (5 – 10) to review the entire product backlog
5. Have the Product Owner ask, “what do we want to groom?”
6. Watch as the team jumps into action and begins discussing ideas and grooming the backlog
7. If progress stalls the Scrum Master is free to jumpstart the process with a few short prods to action
8. When complete with at least two sprints worth of groomed backlog the Product Owner can wrap up by reviewing what was accomplished and how these accomplishments support the product vision and goal.
9. Then, it’s back to work for the developers except now they have a clear idea of what work is coming next.

Example of well groomed backlog

Here’s a quick example of a few product backlog items (PBIs) that have not groomed and a few that have.

Can you spot which PBIs are groomed and which aren’t?

PBI 1 Enable two factor authentication

PBI 2 Improve accessibility by improving our Lighthouse accessibility score from 73 to above 85.

PBI 3 Train and deploy a CNN model to a cloud endpoint and verify results with a holdout dataset scoring above 98% accuracy. The model must beat the current model’s F1 scores by 5% or more. Effort: 21

If you guess PBI 3 you’d be right 😃 . Here’s why.

PBI 3 is the only PBI that has been groomed to the point that it is clearly defined. It is clear what work needs to be done. This includes metrics I can verify such as “Model must beat current model’s F1 scores by 5% or more”.

It also includes test criteria to ensure quality, “verify results with a holdout dataset scoring above 98% accuracy”.

Finally it has been estimated and assigned a score of “21” for effort.

That 21 is 21 points of effort as it’s best to estimate using effort to get more accurate estimates early in a project.

A PBI with a well defined scope, testing criteria, and estimated effort = groomed. Bingo!

PBI 3 has a well defined scope ✅

PBI 3 has testing criteria ✅

PBI 3 has an estimated scope of work ✅

On the other hand, PBI 1 meets no groomed criteria.

PBI 1 does not have a well defined scope ❌ (what type of 2FA?)

PBI 1 does not have testing criteria ❌ (how will we know 2FA works on iOS/Android?)

PBI 1 does not have an estimated scope of work ❌

Twelve Science back backlog practices

According to research into the product backlog there are 12 practices worth understanding.

1. Balanced teams allow experts in all domains to help build backlog
2. Dual track agile one track of people understanding the customer and another understanding how to build the product
3. Stakeholder mapping provides clarity on who stakeholders are and what they want
4. Interviewing allows direct contact with customers using interview conversations
5. Personal modeling creates functional personas to guide product development
6. Affinity mapping organizes data from interviews to show clusters and trends
7. Design studio uses design thinking and prototyping to view many possibilities
8. Sketching/Mockups drawings and visual presentations of possible products
9. Usability testing let users try your mockups
10. Writing user stories describe how customers will use your product and why to guide development
11. Story showcasing Build a team-wide understanding of stories
12. Accepting stories evaluating stories and ensuring agreement

These twelve research backed backlog practices should give you tons of ideas.

Imagine you do customer interviews to get ideas. Then you use affinity mapping to cluster ideas around features. Finally, you use sketching to draw out the ideas.

Presto! Now you have tons of customer focused ideas that are ordered and understood by the team.

Do a quick PBI estimation session and you’ve got clean, ready, and valuable backlog.

That’s just one example. With 12 different activities above you have

In theory, you should have 12! options or 479, 000,600 different options.

That’s options!

Going deeper with product backlog

Let’s explore the backlog with more detail.

Everything in the backlog is a generic unit of work to-be-done. This most generic “to-do” is a product backlog items (PBI).

The PBI is the most inclusive and general category in the backlog.

Let’s use an analogy to clarify PBIs.

Calling a car “car” is the most generic way to refer to it.

The next level of specificity may be calling it by the brand, “It’s a Toyota”.

Going even more specific you could say, “It’s a Toyota Yaris.” including both the make and the model.

How about, “Toyota Yaris, 2008”

Now we’re getting really specific and the same is true of your backlog.

You can refer to something in your backlog as a PBI (like calling it “car”).

But you could also be more specific and call it a user story. This is a type of PBI. In the car analogy this would be, “Toyota”.

Then you could further describe if it was a feature user story. This is a user story adding a feature to your product. Think, “Toyota Yaris”.

There are other categories of PBIs such as epics, bugs, data gathering, research spike, and more.

The point is not to define every type of PBI but to show there are many types of PBIs.

You want to know these names and catagories so you can follow conversations about backlog. When someone talks about a user story it helps to understand that category.

You don’t need to label or categorize PBIs. The point is not to label and organize everything. The point is to know there are many options and help you pick the right option so you build the right product.

Everything in Scrum is about building the right product at the right time.

Acceptance criteria

Acceptance criteria is the list of things that must be true for a PBI to be done.

These criteria should be the same across a broad group of work.

Acceptance criteria for a construction project should include, “job site cleaned”.

Every construction project needs to be cleaned before the job is complete. This means we can apply this acceptance criteria to every job.

Having acceptance criteria makes it faster and easier to complete backlog refinement.

Each PBI that fits into a certain category of work should get the same acceptance criteria.

If every construction project has a list of things that must be done, adding them to each new project is nearly automated. You need only cut and past the acceptance criteria into each PBI.

Many teams overlook acceptance criteria and therefore spend more time and effort building a shared vision of what “done” means each PBI.

Move faster and be more efficient by storing your acceptance criteria in an easily accessible spot and reusing them.

Estimation and PBIs

Estimating user stories can be fast and fun. There are two tested and effective methods you should consider.

Affinity sizing

Affinity sizing can be really fun. Here’s how it works

1. Gather all your PBIs into one spot
2. Make columns with the labels S, M, L, XL
3. Move one item into M that everyone agrees is a medium amount of effort
4. Each team member moves one PBI into a column then goes to the back of the line
5. Each item can be moved from one column to another 3 times then it is fixed in that column
6. The exercise continues until everything is in a column
7. Assign the following points to everything in these columns: S=3; M=5; L=8; XL=13
8. Done!

If you do this your entire backlog will be estimates

Scrum Poker

Scrum poker lets you discuss PBIs in greater detail and is my preference.

Here’s how it works.

1. Pick a PBI
2. Describe the PBI
3. Vote using cards that follow the Fibonacci Sequence
4. If all votes are within 3 (2, 3, 5 are within 3), average the votes and proceed
5. If votes are greater than 3 sequence spaces apart (2, 3, 8 are four apart) stop
6. Have the high vote explain their vote
7. Have the low vote explain their vote
8. Revote
9. Repeat up to three times then throw out the low and high vote, average the rest of the votes and proceed

I prefer this approach because it allows the team to discuss the work in more detail.

Scrum Roles

No article about Scrum would be complete without discussing the three roles.

Scrum Master

The leaders who serves. This is person keeps the team focused, protected, and on schedule.

Their primary task is to increase productivity by removing impediments.

You can become a Scrum Master by taking a credentialed Scrum Master course.

Here’s how to become a scrum master.

Product Owner

The product owner is the person responsible for the value of the work produced. If your product finds product-market fit and has massive growth and profit that’s because of a great Product Owner.

If your work flops, that’s also the product owners responsibility.

Key tasks include backlog grooming, customer interactions, and product vision creation.

You can become a product owner by taking one of several product owner courses.

Developer

The developer is the heart of the team because they create the product.

Developer is a software role, but in Scrum it is used to anyone on the team who builds the product.

That is why this role can be assigned to a tester who is part of team. It can also be applied to a marketer if it’s a marketing team.

Sprint

The sprint is the arbitrary length of time used to measure work progress. It is between one to four weeks long.

The reason for Sprints is to have a repeatable unit of time to measure how much work is accomplished.

By having the same unit of time you can measure the amount of work completed and compare that number from Sprint to Sprint.

The sprint should be just long enough to complete meaningful work and the shorter the better.

If you can use one-week Sprint, do it. You’ll get more feedback.

Scrum Stats for 2023

• 71% of US companies use Agile source
• 61% of US companies use Scrum source
• Big tech companies neither mandate or prescribe Scrum for their teams
• 42% of Scrum projects are successful source
• 13% of waterfall projects are successful source

Summary

In this tutorial we’ve reviewed what the backlog is and how to groom it. We’ve shown 12 activities you can do to prepare you backlog and ensure it’s customer driven. Finally, we reviewed the roles of Scrum and presented some statistics for you to consider.

If you like this post, you might enjoy a few things over at https://drink-mix-artist.com/ where I write from time to time.