It’s easy to have a huge Product Backlog. Keeping it short is way more difficult. It requires many things to be in place.
Two important examples are:
✅ A clear, specific, guiding purpose
✅ A Product Owner with a mandate to say ‘No’ to potentially great ideas that don’t fit the time and budget you have.
Required skill
The experiment itself is easy to do. What comes out of it may not.
Impact on survival
This experiment has a tendency to reveal the huge impediments that are making it hard for your Product Owner to work empirically.
The purpose of this experiment is to add a constraint to the length of the Product Backlog and see what happens next.
Steps
To try this experiment, do the following:
1️⃣ Together with the Product Owner, define a constraint for how long the Product Backlog can be before items have to be removed. There is no single number that works best for all scenarios. 🤷♀️
You want a number that results in a Product Backlog that you can take in in one (long) look and have a sense of what is going to happen. Generally, shorter is better. Many teams like limits between 30 and 60 items.
2️⃣ If the Product Backlog of your team is already ordered, you can jump to the next step. If not, work together with the Product Owner, the team, and stakeholders to re-order the Product Backlog with the purpose of the product in mind.
3️⃣ Invite the Product Owner to remove all the items that are beyond the constraint. Moving them elsewhere on the wall or to another list in JIRA doesn’t count. Actually, throw them away. If teams have physical boards, we always like to bring in a trashcan to do this in a very visible way. 🗑️
Does it hurt? 😧 Yes. Will people object or faint? Probably. But by being very clear about what is going to happen and what isn’t, you create transparency for your stakeholders about what to expect.
4️⃣ Visualize the constraint on your Product Backlog. If you have a physical one, you can simply limit the space you have. Most digital tools support list constraints.
Make sure to clearly show the purpose of the product next to the constraint, as this is the touchstone for each decision about what to keep and what to throw away.
5️⃣ Encourage the Product Owner to frequently clean up the Product Backlog to make the best use of the items you can put up there.
Our Findings
- This experiment can expose many impediments. It may show that your Product Owner has no say in what goes on the Product Backlog. Or it may show that your team spends too much time refining items way down the Product Backlog, making it feel wasteful to throw all those specifications away. But this experiment can also show that there is no clear guiding purpose for your product, something that helps to make decisions about what goes on the Product Backlog. Whatever the case, sticking to the constraint is a great way to keep the focus on solving those impediments instead of working around them.
- Be clear, but also respectful of the items you remove. Each of them represents a potentially great idea for the product. And when items are removed from the current Product Backlog, they may reappear if they are great enough for the product you’re trying to build;
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.