You got in the Agile game to be nimble, react to changing market conditions and opportunities, and work collaboratively with your development team to rapidly bring solutions to market without being bogged down in processes and endless meeting. So how did you end up having to manage a seemingly endless laundry list of development items otherwise known as your Product Backlog?Let’s start by taking a look at what’s actually in there:
The above could kindly be referred to as a “dog’s breakfast” of various shapes, sizes, origins, and purposes. You’re not just picking Widget A vs. Widget B, you’re prioritizing Pebble C vs. Boulder D.All Product Backlog Items (PBIs) are not created equal. Some might take a single developer a few hours, while others might require weeks or even months of work across multiple teams. Some might be major game changers for your business while others have questionable needle-moving merit.“The Product Backlog can contain anything. Anything relating to the product that is. Bugs. Enhancements. Whole projects. Issues. Risks. Anything,” says Kelly Waters, author of All About Agile. “Having said that, items on the Product Backlog should ideally be expressed in business terms that are of some value to the user (or customer, or business). Not as technical tasks.”
You could just leave it alone, you know, adding new PBIs to the pile as they come in and then sifting through the list for just the right mix of features and bug fixes to include in your next release, like a kid searching for treasure in the toy box after their dentist appointment. But this would not only make individual release planning extremely inefficient, it also harms your credibility and impedes your ability to align your product with overall strategy.The Product Backlog “remains the single source of truth” and thus it is important to keep it limited to worthy features and enhancements.“Remove those features that cloud your Product Backlog,” says Gunther Verheyen of Scrum.org. “Remove those features that always sink to the bottom of what you plan for your product, and never get implemented. If those features are really valuable, they will pop up again at some point in time.”A backlog must be a living, breathing and evolving tool, otherwise it can result in diminished opportunities for innovation and actually work against the nimbleness and responsiveness that Agile is intended to foster.“If we simply “work from the backlog” we may not pay the necessary attention to determining how best to evolve the product and instead go for the easy option of simply churning out the stuff already on the backlog,” says Agile Coach Neil Killick. “The backlog can quickly become the focus rather than the product itself, and as it continues to grow it becomes increasingly difficult to prioritise or focus on the highest value things to build.”Not only should you be keeping only the best ideas on your backlog, you should also make sure you’re not letting items stick around just because you don’t want to hurt people’s feelings by telling them that their idea or suggestion simply didn’t make the cut.“Please don't make the mistake of having things on the backlog that don't have a clear value attached to them or that are unlikely to ever get done,” says Marc Abraham of notonthehighstreet.com. “Having a 'messy' or endless backlog can be demoralising and can lead to a loss of focus.”
An untamed product backlog can be a rather daunting collection of PBIs to make any sense of, but one tried and true tactic for bringing some order to the chaos is to embrace themes for your backlog organization.“A theme is really nothing more than a collection of User Stories, its size is simply the size of the stories within it. Themes are good because they allow a product owner to focus on a big target for the next iteration,” says Sean McHugh of Axosoft. While a theme may contain dozens of User Stories, “ a product owner can focus on just that one area by deciding to focus on the theme.”Tagging each one gives you some common threads running through groups of PBIs, so you can now assess items not as one-off requests but part of a larger, well, theme.Assuming your product is generating revenue (or WILL generate revenue once it ships with a particular feature intact), you can also use “Cost of Delay” as a driving factor in your backlog prioritization.“The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales,” says Johanna Rothman of Rothman Consulting Group. “With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.”Unfortunately, each PBI can’t just be prioritized in a vacuum, as many features and fixes are interdependent. While it would be great to, for example, get an alert on your banking app when your balance dips below $500, you need to first have an alert system in place, then have a balance monitoring component built, have some settings options…you get the idea.“The Product Backlog is not guaranteed to represent an ordering of PBIs by either value or priority. You can’t just assign priorities to PBIs — whether they come from ROI or importance to the business or anywhere else — and then prioritize the backlog on the basis of those relative values. You must consider the entire backlog of PBIs together,” says James Coplein of Gertrude & Cope. “To use the term ‘ordering’ instead of ‘prioritization’ also makes it clear that the Product Owner must make decisions. He or she cannot just say “These five items are all priority 1; these three items are priority 2” and so forth. The product owner must deliver a totally ordered Product Backlog.”While backlog ownership is one of the chief responsibilities for Product Owners/Managers, some organizations prefer to make backlog refinement a more democratic process, with each backlog item being assigned an internal champion.“The champion would then give an elevator pitch on the importance of their backlog item,” says Derek Morrison, Head of Product at Tesco, before everyone votes on the relative priority of each item. The votes are then tallied and the list it sorted by which item got the most points. “Everyone embraces the outcome because: they participated, there was total transparency, and we all bought into the goal for the coming quarter.”
Each time you touch your backlog, you’re using up your own precious resource…your time! So it’s in your own best interest to whittle away the list into something that is much faster to review and re-order.After a few Sprints, it might become obvious that that “great idea” someone gave you is simply destined to never make the cut in the near future… or ever. Instead of dodging the truth, it’s your job to make the hard decisions, so rip off the bandage quickly and make it clear what you’re doing.“If something is a bad idea, the Product Owner should explain to whoever requested it why they are removing it from the Backlog,” says Waters. “However, if something’s not such a bad idea, although never likely to be done, just put it in its rightfully low place on the Backlog and explain to the requester where it fits with priorities.”If you’re resistant to deleting a “perfectly good” PBI (other than the fact that you’ll never get around to actually implementing it), then you can build yourself an “attic” for long-term storage.“The idea behind the attic is that it is a special classification of product backlog items where, in the normal course of work, you never see the stuff that’s in the attic,” says Agile coach Hans Samios. “You then go through your product backlog and decide which items need to be put up into the attic.”Not sure when it’s the right time to remove a PBI from the list altogether or send it up to the attic? You can give each PBI an expiration date.“Stale items that have been on the shelf for a long time and have never risen up in your ordering are most likely not needed,” says Agile coach Dhaval Panchal. “If they are truly needed, they will emerge again. Set an expiry date say – 2 months or 6 months for items in the product backlog."Also key to kicking the riff-raff to the curb is ensuring that PBIs are still strategically aligned with your product’s goals and those of your organization. Whether you’ve made a major pivot or simply ruled out a particular vertical or product line extension, if the item in question doesn’t make strategic sense, then it shouldn’t be taking up space on your backlog.Another way to quell the endless backlog grooming is to make sure you’re not creating even more work for yourself by turning bite-sized stories into crumbs. Instead, be specific without being granular; don’t decompose user stories to such small sizes that things become unmanageable.“Sometimes large stories are just fine as-is. They are more understandable and estimatable,” says Robert Galen, author of Scrum Product Ownership. “They also drive spikes when appropriate and allow for a team to swarm around the story. Most importantly, they allow the details to emerge just-in-time within the sprint, rather than trying to sort through everything in advance without working on code.”Most importantly, don’t let it pile up! Backlog refining or grooming should be happening once or twice per week. This doesn’t mean you need to schedule a massive all-hands meeting, but you should be constantly reviewing, updating, and tweaking your backlog so it is really reflective of what your organization is focused on right now and what you know about the product’s current capabilities (vs. what the product did when the PBI was initially thrown onto the pile).Chunk your backlog work out so that you can do it in small bursts. This way, it will shift from a burdensome task to a delightful break from the craziness of your day. Plus, you will develop great recall of what’s on the list, where it is, and why.