Too Many (or Too Few) PBIs
Product owners get nervous when you suggest that some of their product backlog items should be deleted. Really nervous. Sometimes they’ll agree to cut the items from the product backlog…and then paste them into a secret product backlog, just in case. Of course, we know that there can be only one product backlog, so the PO having a separate, secret product backlog is inherently a bad idea.
An overgrown product backlog is hard to navigate, which makes it difficult to get back to the roots of your vision and see the items that will bring it to fruition. This causes communication to break down both within the Scrum team and with stakeholders, because it’s impossible to gauge your progress and where you will be in the near-term and long-term future.
The opposite issue, a product backlog that lacks substance, is equally dangerous. A shortage of product backlog items leaves teams scrambling during sprint planning because there’s no future for the product owner to discuss with stakeholders. Having a nearly empty product backlog is like going to the grocery store when you don’t have a list—and you’re hungry. You’ll leave the store with whatever intrigued your stomach, but with no clear meal plan for the days ahead.
So how many product backlog items should you have? Just enough to define a short-term, mid-term, and long-term future for your product:
-
Short-term items (a.k.a. stories) should have the most detailed requirements. It’s good to have two to three sprints worth of such items that are ready for the development team to bring into a sprint. These items should contain enough detail that the development team feels confident bringing them into a sprint, but not so much detail that there’s little flexibility in the outcome.
-
Mid-term items (a.k.a. features) are things that will be accomplished 3-6 months from now. They should have enough detail for the development team to know the direction that the product is heading. Invest minimal time here. Remember, PBIs are emergent—things will change before you get to these items. Rough estimates and sizing are perfectly fine for these PBIs.
-
Long-term items (a.k.a. epics) can be vague. They should describe what the product might contain in the distant future. These items are too large to be finished within a single sprint, are often unclear, and will need multiple refinement sessions to become actionable.
So what do you do if your product backlog is too crowded, too sparse, or doesn’t clearly define the future of your project? There’s no panacea for successfully refining your product backlog, but here are some tips.
Make Product Backlog Refinement Fit Your Situation
There’s no single, prescriptive technique that you can use to ensure that your product backlog is in good shape for future sprints. Product backlog refinement—where the development team and product owner collaborate to add details, estimates, order, and/or decomposition to the product backlog—can occur daily, weekly, or once a sprint. The exact timing doesn’t matter as long as the refining gets done.
It’s perfectly acceptable for the product owner to delegate and ask the development team to refine items informally as needed. You may also choose to make refinement a formal event that occurs on a regular schedule within your sprint. No matter what technique and schedule you choose, inspect and adapt during sprint retrospectives to find out what works best for your Scrum team.
Though you may still hear that phrase used by some Scrum teams, the authors of The Scrum Guide changed “product backlog grooming” to “product backlog refinement” several years ago. The term “grooming” has extremely negative connotations in some parts of the world. “Product backlog refinement” sounds more professional. It’s important to keep up with changes like these so you don’t unintentionally offend anyone. That’s one of the many reasons we recommend reading The Scrum Guide regularly.
Don’t involve everyone
Many people think that, in self-organizing development teams, everybody needs to be involved in everything, but that may not be true for your team’s product backlog refinement sessions. If it feels like a waste of time to involve everybody, then don’t. As the Scrum master, you can talk to the development team about who should attend a given refinement session, and have them decide. It’s important that everyone on the development team understands what’s in the product backlog, especially prior to sprint planning. That doesn’t necessarily mean everybody has to be involved in refinement all the time. Trust them to talk to each other.
Estimate only when necessary
The later you estimate, the closer you’ll be to the work and the more relevant that estimate will be. Some people argue that an accurate estimate is impossible and a waste of time when working in a complex profession like software development. While it’s rarely possible to estimate exactly how things will play out, creating estimates is still worthwhile for two key reasons:
-
Estimates allow the product owner to decipher the return on investment of a PBI when weighing the expected value of a feature against the forecasted effort that will be involved in building it.
-
Estimates provide the development team with details that can help them determine what might need to happen to bring the item into a sprint. For example, it can help them determine whether a single PBI could (or should) be split into multiple items. Conversations about the work are often more important than the actual estimate.
The act of estimating helps the Scrum team understand a product backlog item. It’s about the conversations that are sparked by the process, not the actual estimate. When and how you estimate product backlog items is entirely up to your team and should fit your situation. As a Scrum master, it’s important to know multiple estimating techniques that you can teach your team. A good resource for learning effective agile estimation techniques is Predicting the Unpredictable by Johanna Rothman.[10]
Don’t get too far ahead
If you’re refining product backlog items that the development team won’t work on for several months, stop–you’re wasting your time.
Requirements are often one of the most unstable aspects of software development. It’s difficult to accurately capture a customer requirement, regardless of the format you use or the amount of effort you put into it. A product backlog with stale items means you wasted time creating requirements that are no longer relevant. Stick with having one to two sprints’ worth of “ready” items in the product backlog. Likewise, don’t assume that every aspect of a product backlog item needs to be explicitly defined. Allow some room for conversations and creativity about the implementation during a sprint. Ambiguity gives the dev team the opportunity to talk about the best way to complete the PBI and find creative solutions.