A well kept Product Backlog is pivotal to the success of a Scrum Team. Imagine the Product Backlog as a gas tank in a car. Keep enough good gas in it to get to your next destination. Fill it with bad gas and your car might clunk along or not move at all. No gas at all… well you get the idea.
Recently I’ve run across a few Product Backlogs that have hundreds or even thousands of Product Backlog Items (PBIs). It seemed as though the Product Owner filled up several portable gas cans and put them in the trunk of a car. The problem with gas is it can only be stored in a gas can for three to five months before it goes bad.
If the Product Backlog has turned into a comprehensive wish list of hundreds or thousands of items, is it easy to decipher what’s valuable? Can the Product Backlog be transparent and open for all to see if nobody understands it? Are you allowing yourself to fall back into waterfall by explicitly defining requirements months in advance?
If any of this sounds familiar it might be time to purge the Product Backlog. Removing unnecessary PBIs is not as scary as it might seem. It’s as important as adding new items. Here are a few things to think about as you go through the Product Backlog:
- Is the PBI Valuable?: Is there value in adding the PBI into the product? No matter what way you quantify the answer to this question, always think value first and remove a PBI if it is not valuable.
- Shelf Life: Has the PBI been sitting on the backlog for months without any movement on it? Perhaps it’s time to either bring it into focus or come to the realization that it just isn’t something valuable to add to the product.
- Vagueness is okay: It’s okay for the bottom of the Product Backlog to be vague with large, unknown future requirements. You can put notes, wireframes, or other artifacts on a vague PBI and decompose it when it becomes the most valuable thing. Don’t be in a huge rush to decompose something that isn’t going to be worked on anytime soon.
- Two to Three Sprints of “ready” work: The top of the Product Backlog is the work right in front of the Development Team. Strive for two to three Sprints of PBIs that can be taken into a Sprint by a Development Team. Any more and you might be ahead of yourself, any less and you might run out of gas during Sprint Planning.
- Be suspicious: Justify why something should be placed on the Product Backlog and be suspicious about everything you add. Is it necessary to the success of the product have this PBI?
The Product Backlog must be meticulously monitored and refined during the development of a product. Refining includes removing unnecessary PBIs that may be clouding a key aspect of the Product Backlog: transparency.