Streamline Your Agile Requirements by Avoiding Bloated Backlogs
Moving from traditional requirements to user stories seems like a simple task. Identify a user, then get them to tell you what they want and why. No problem, right?
When I first started writing user stories, I really enjoyed the simplicity of the format. It wasn’t until I attended some product workshops that I had a most profound learning moment: We often unintentionally waste brainpower creating bloated backlogs.
During one session, we worked through an activity brainstorming user stories for various personas. Sixty minutes and forty-five user stories later, the team was quite proud. Our facilitator congratulated the team, saying, “You’ve done a lot of work here. A lot of work!”
That wasn’t quite the reaction I was expecting.
It became clear that even a simple technique like brainstorming could inadvertently revert to traditional waterfall ways. In my own practice, I realized that I had a habit of producing a long list of user stories, resulting in a bloated backlog. That was before I understood the benefit of clarifying product partners, their priorities, and the utility of exploring product options.
Recognizing a Bloated Backlog
A bloated backlog results from teams accumulating huge backlogs of requirements, usually in the form of user stories. Bloat takes place when you retain stories in your backlog that are either less important, unnecessary alternatives to other stories or stories of low priority. Retaining every possible story for building the product weighs down the backlog while squeezing (or obscuring) the highest-value stories.
Recognizing patterns that lead to a bloated backlog is a good place to start. Some of the phrases below will likely sound familiar.
| Habit | Comments that can lead to bloated backlogs |
|---|---|
| Can’t say no | “How does this chat feature distinguish us from the competition in the mind of the user?” “I want to be inclusive—every stakeholder should have a voice.” “All stakeholders need to be happy.” “It wouldn’t have come up if it weren’t valuable.” “If we just accept it, maybe he’ll move on.” “She’s our boss’s boss, so we can’t just say no.” |
| Just in case | “We don’t want to forget what we talked about.” “It isn’t a priority now, but maybe we’ll need it in the future.” “Just move it to the bottom; we’ll get to it eventually.” “Even if nobody has spoken to a stakeholder about this, I know it will be valuable in the future.” |
| The mother of all backlogs | “It will be easier to track priorities if we include everything recommended from all the teams.” “Just ignore everything below this point. We’ll never get there anyway.” “What about audit? We need to track everything that was ever suggested.” “It was my idea, and I think it is brilliant. We can’t let it go no matter what.” “We can’t just get started. We’ve got to have a deep-dive session with all the stakeholders and come up with a complete list.” “We need to exhaust each dimension before moving on.” |
When adding more and more stories to your backlog becomes a common response, that’s a clue that the team may need to adjust its approach.
At a minimum, try to understand why unplanned and often unproductive side trips are taken to discuss less important backlog items. You want to focus on fewer items that are higher value rather than waste time sifting through that bloated backlog.
Explore All the Product’s Dimensions
The best way to help minimize the risk of a bloated backlog is to optimize the time spent defining and refining the backlog. Stakeholders from the business, customer, and technology communities should collaborate as product partners to discover the product’s needs.
This requires providing clarity and transparency about value. [1] Explore and evaluate options, and if something is not a priority, stop discussing it.
The trick is understanding when you’re going off track or if your priority discussions are distractions in disguise. Exploring the product’s dimensions can help.
The 7 Product Dimensions [2] described below provide a path toward shared understanding and can help frame backlog discussions. These areas give a holistic view of backlog items, emphasizing that no single dimension is sufficient by itself—all seven are necessary.
Once you’ve explored the possibilities for the 7 Product Dimension, think about the product priorities. Identify the top three priorities and make them visible. Keep them at the forefront any time you discuss user stories.
As a story is identified, explore that story against those top priorities. Don’t try to recall the priorities from memory; write them down and display them during story conversations. Consider the following:
- Does the story align with the priority items? If not, don’t spend any more time on the story. Move on.
- Are you unsure whether the story might be more important in a future project? If the story is important, it will come up again later and can be added to the backlog then. Often these “side trip” stories are less valuable to the product outcomes and detract from the stories that are important.
- What’s the most important item at any given time during the project lifecycle? If the priorities are unclear, get clarity. Otherwise, distractions are likely to creep in, possibly resulting in bloat.
- Who are the most important product partners for your next delivery cycle, and what do they value? Depending on the situation, specific users or business partners may be more valuable to focus on than others. If a partner’s value is unknown or a best guess, it is much harder to understand what’s most important.
Developing Good Habits Takes Time
A key benefit of considering all of a product’s dimensions is that it provides just enough structure to drive meaningful requirements discussions yet is not so prescriptive that it stifles creativity.
To help minimize bloated backlogs and ensure that you’re focusing on the right priorities, there are several questions you can ask:
- Have all product dimensions been explored and evaluated to determine relevancy? If, for example, you focus solely on the two dimensions explicit in a user story (user and action dimensions), important conversations about data and business rules will be missed. More than two dimensions are needed for a shared understanding.
- Are you focused on one dimension for so long that a given story or feature takes up too much time and effort in your refining sessions? In your next session, use a time box to explore each dimension. It might feel uncomfortable at first, but with practice, it will get easier. Some product dimensions will only need a few moments to discuss. But don’t skip a dimension or focus on your favorite dimension because it’s easier than the others.
- When using the product dimensions, is it clear when to stop or when you’re going off track? Take every opportunity to pull out your top three priorities and use them for guidance.
- Do the product owner and team understand the product’s top priorities? Is there a shared agreement?
- Is there a clear, concise, and compelling product vision that is known to all and understood consistently?
- Are there other types of waste occurring during backlog refinement?
Learning a new approach to avoid a bloated backlog requires patience and perseverance. As in any journey, you won’t get where you want to go instantly; avoiding bloated backlogs takes time to learn. Explore and evaluate product options across the seven product dimensions continually and iteratively and you will start seeing improvements in your agile efforts.
Want to Learn How to Define and Refine a Healthy Product Backlog?
Attend our Agile Requirements: Moving from Vision to Value two-day, immersive course coming to Toronto, Ontario, Canada October 30 – 31.
References
- Ellen Gottesdiener and Jeff Sutherland. “Backlog Refinement Takes You from Vision to Value.” EBG Consulting (blog). September 9, 2016. https://www.ebgconsulting.com/blog/backlog-refinement-takes-you-from-vision-to-value
- Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting. 2012.
Note: This blog was originally posted on Agile Connections.
Leave a Reply