Agile Product Backlog Grooming Iceberg

An understanding of the Agile Product Backlog Grooming process is important. A metaphor of an “Iceberg” is often used to visualize how the process works.

What Is Product Backlog Grooming?

The “Product Backlog” in an Agile/Scrum environment is a prioritized queue of work to be done. It normally consists of user stories which are short descriptions of features and capabilities that must be satisfied. It may also contain other work to be done such as software bugs or refactoring. When the Product Backlog is initially created, it may be only defined at a high level and the Product Backlog Items are progressively refined and further prioritized as the project is in progress. That process is called “Product Backlog Grooming”. It is generally done continuously throughout the project in parallel with the development effort. The objective of Product Backlog Grooming is to have the Product Backlog Items sufficiently-defined when they are ready to start development.

The Product Backlog Grooming Iceberg Approach

I like the idea of thinking of the Product Backlog as an “iceberg” as shown in the diagram below. I believe this iceberg Idea was originally created by Mike Cohn):

The “iceberg” idea is that:

As you pull items off of the top of the iceberg,
Other stories that are at lower levels in the iceberg move up to take their place

The process of developing stories and moving them up the iceberg goes on continuously to feed the development process. A Kanban process with different stages of definition for stories fits this process very well.

How Far Do You Need to Plan Ahead?

A key decision is “How far do you need to plan ahead to stay ahead of the development process?”

A typical Agile approach of Product Backlog grooming is sometimes focused primarily on limiting the backlog to only about 2-3 sprints ahead
That approach involves only doing grooming only as needed to get stories ready for development

There can be a big difference in the Product Backlog Grooming depending on what level of planning the project requires:

Totally Adaptive Approach

If your project can be totally adaptive and doesn’t require a plan, you can probably live with that approach. You could completely define the Product Backlog “on the fly” as the project progresses.

More Plan-driven Approach

However, in many situations there is a need to have a plan either at the release level or project level for the project. In that situation, it’s very difficult, if not impossible, to

Limit the definition of the backlog too much and
Also be able to have some kind of plan of where the project is going

Product Backlog Grooming Guidelines

Here are a couple of suggested guidelines for this process:

1. You Never Want the Development Team Waiting for Stories to Go Into Development

The number of stories that are fully groomed and ready to go into development should always be far enough in advance to keep the queue from going empty. You always want to prevent developers becoming idle waiting for stories to develop.

2. Logical Stages for the Grooming Process

There are logical stages that the grooming process for the rest of the backlog goes through. Those stages should align with whatever planning objectives you need to meet. For example, if there is a need for release-level planning or project-level planning to forecast a plan and an estimated schedule, the Backlog needs to be sufficiently-defined far-enough in advance to support that objective.

3. Product Backlog Grooming Can Be a Very Time-Consuming

Product Backlog grooming can be a very time-consuming process. The time for grooming of what’s coming next needs to be built into the current sprint or it may not get done in time to keep up with the development effort.

4. Using People on the Team Efficiently

Using people on the team efficiently to do backlog grooming can be a challenge.

The developers who are going to take responsibility for the development of the stories need to be involved in the final stages of grooming. Prior to taking the stories into development, there should be a common understanding of the intent for the stories
However, it might be a significant drain on the team if the entire development team became deeply engaged in the very early stages of backlog grooming. A large portion of that effort can be done by the Product Owner and/or a Business Analyst working with the Product Owner supplemented by inputs from the development team as needed

You can find related articles on the topic of “Agile Requirements” here: