For quite a while now, I’ve been teaching my students and customers about backlog grooming (for those of you unfamiliar with the term “backlog grooming,” this is a regular work session where the Scrum team learns about what’s probably coming in the next Sprint, slices the backlog items into smaller, simpler pieces, and re-estimates them). The primary objective of backlog grooming is to learn enough about the backlog item that we can reduce it in size and complexity so that, when Sprint Planning begins, the team is working with small items that the team already knows and can easily build in less than a week.
I also warn my students that grooming too far ahead can be a waste of time — the further we look into the future, the greater the risk that we will spend time on something that will be removed from the project before we actually get there. I teach my Product Owner students not to allow their teams to groom too far into the future because doing so will also increase the size of the backlog that the Product Owner is trying to manage by more than a factor of five (often as much as ten).
Recently, however, I’ve also begun teaching that backlog items themselves have a useable lifetime that seems to be directly proportionate to their size and complexity. A large backlog item can survive on the Product Backlog for a much longer period of time before it has to be re-assessed for feasibility and appropriateness. However, as smaller backlog items are created, their lifetime is proportionately shorter. For example, one of my customers has a number of teams that groomed their backlogs considerably further in to the future than the Sprint-and-a-half I typically recommend.
In addition to the anticipated difficulties being experienced by the Product Owner because the backlog is now eight times bigger than it was at the beginning of the project, what we’re also seeing is, as we start addressing backlog items created three or four Sprints ago, the assumptions in place when the backlog items were created is no longer valid. As a result, the teams basically have to re-assess the backlog item (and often re-estimate the item), evaluating the item against the current reality. Its looking more and more like it would be less effort if the teams simply threw out these older, smaller backlog items and just re-groomed them from their original “parent” backlog items.
So, now I have another reason to avoid grooming too far into the future:
- There’s an increased potential for waste because you may groom backlog items that will be removed from the Product Backlog.
- Your Product Owner will have a VERY difficult time prioritizing and maintaining a backlog that has swelled to 5x or 10x its original size.
- Backlog items have an expiration date based on the size of the item. Groom too early and you’re DEFINITELY wasting your time.
Have fun!!
