Bad Product Backlogs Are...Bad
In a recent article, Nick Killick identifies a very real problem. Software development teams—agile software development teams—are getting caught on the merry-go-round of incremental product improvements and are failing to create innovative products. Killick has painted the product backlog as the culprit.
The product backlog, as Mike Cohn describes it, contains a prioritized list of features, bugs, “technical work,” and knowledge-gaining activities that the team needs to perform. This is definitely an accurate description. However, describing a person as being almost 99 percent comprised of oxygen, hydrogen, carbon, nitrogen, phosphorous, and calcium is also accurate. It is not, however, a particularly good description for educating us about what people can do.
Killick points out that an uninspired product backlog is “nothing more than a list of up-front requirements which may as well be in a BRD.” I completely agree. He describes some organizational anti-patterns for building a backlog as a list of “stuff to do next” that are the analog of writing a recipe for creating a human being that starts with “first, add 12 gallons of water.” I completely agree that broken recipes for creating a product backlog will yield a broken product.
A perspective that helps is to start by acknowledging that requirements live in the market, not in the backlog, and they change over time. A product roadmap provides the long view—“here is our current intent of when we will address particular problem areas, for particular customers (or in support of particular themes).” Blaming roadmapping for the evils of bad roadmaps has happened too. A product roadmap should show the next few quarters and the next couple of years—not looking out too far and not going into too much detail.
Within the release cycle that enables realization of the roadmap, the product backlog exists to prioritize what the team will work on within the context of the roadmap. The backlog is not a list that grows indefinitely with every idea or request to be prioritized (and occasionally culled).
The only items that make it into the backlog are the items we intend to try to do. Items leave the backlog either when they are being worked on—by moving to a sprint backlog—or when they are intentionally discarded when the team decides not to do them after all.
Neither a product roadmap nor a product backlog is intended to be a comprehensive description of the market. That is very valuable, but it is a separate artifact. Neither a product roadmap nor a product backlog is intended to be a holding pen for every request that might someday be fulfilled. When a team uses either tool for either of these purposes, it will absolutely cause the problems Killick describes.
Don’t discard product backlogs. Just stop using them incorrectly.
