Agile Product Backlog Grooming “Iceberg”

An understanding of the Agile Product Backlog Grooming “Iceberg” is important. A typical Agile approach of Product Backlog grooming is sometimes focused primarily on limiting the backlog to only about 2-3 sprints ahead and doing grooming only as needed to get stories ready for development. That is a big difference between a “pure” Agile approach and more of a hybrid approach that blends an Agile development approach within a somewhat plan-driven envelope. If your project can be totally adaptive and doesn’t require a plan, you can probably live with that approach and completely define the Product Backlog “on the fly” as the project progresses. However, in many situations (particularly in large enterprise-level projects), there is a need to have a plan (either at the release level or project level) for the project. It’s very difficult, if not impossible, to limit the backlog too much and also be able to have some kind of plan of where the project is going.

For that kind of environment, 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):

Product Backlot Grooming Iceberg

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. (Thank you to Michael Hurst for suggesting that) Here are a couple of suggested guidelines for this process:

  • 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 and to prevent developers becoming idle waiting for stories to develop.
  • There are logical stages that the grooming process for the rest of the backlog goes through and 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 and defined far-enough in advance to support that objective.
  • Product Backlog grooming can be a very time-consuming process and 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.
  • 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 so that there is 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.

Leave a Reply

Your email address will not be published. Required fields are marked *