The Simple Product Backlog Fallacy

Because everyone’s backlog is more complicated…

When some people are taught about agile and the new ways of working, they learn about product backlogs and sprint backlogs as well as how to estimate and manage their work in progress limits. All very good things. Seems simple. Almost like common sense.

Then they try to do it… and it’s WAY harder than they thought.

It’s much easier to teach agile to teams based on the premise that they are doing nothing but building a new product, like a startup team that just got their funding. A simple backlog with a prioritized and sequenced list of work to do. But the reality is always much grittier when the rubber hits the road.

Teams often support old products or old versions of products. There are bugs coming in caused by team members that left the company years ago. There are co-dependencies on other teams or work that may get done in part by one team and completed by another. And often, there’s just a huge variety of work that makes prioritizing feel impossible. With multiple products, new development, maintenance efforts, bugs and support work comes not just a lot of stakeholders and customers to please, but the miserable and difficult task of deciding what to do next.

For this reason, being a Product Manager is the hardest job in the agile universe.

So what do you do?

Identify Current Buckets of Work

As an agile coach, the first thing I like to ask teams about that are having this common challenge is to identify the unique buckets of work they have to prioritize. Separate the work into logical buckets by application, stakeholder, customer segment, or code base, whatever makes most sense to the team. Then think about the level of importance of each of those buckets. Sometimes you get lucky and there are standouts that are clearly the highest priority. But you may be in a situation where everything is important and that’s OK too.

This first step is acknowledging where the team is spending their time. Unfortunately, teams are labeled based on the new development work they have been asked to do, and it is easily forgotten what other things they need to keep spending time on. I’m a big proponent of having teams own everything related to the product lifecycle whenever possible, so this situation is very common.

Understand the Team’s Capacity

Next, is gathering data about what your team is capable of doing. This is best done using some form of “yesterday’s weather”, acknowledging what the team has been able to complete in the past and observing how long those things took compared to what the team thought they would take. Whether you are tracking velocity in Scrum or cycle time in Kanban, you should be able to work out some detailed metrics to help set expectations about what the team might be able to do in the future based on what they’ve done in the past.

Visually Represent the Work Allocations

With this information, the buckets of work and the metrics and measures about work that’s been completed, you can start to approximate and forecast what should be expected of the team. My favorite technique here is to create a pie chart of the team’s available capacity for an upcoming Sprint or time-boxed period of time and present a reflection of the reality of what the team has actually been doing. Start by modeling the recent reality of where the team spends their time to help others understand the work load.

You might, for example, gather your stakeholders and anyone with a vested interest in your future work and show them a pie chart of how the team has been working. Where they spend their time in percentages. This helps set the stage that the team is doing more than just what one particular stakeholder might be interested in, for example. You might even call this aggregation of priorities the “portfolio of priorities” that the team is currently addressing. Keep it simple. I like sharing a simple pie chart to illustrate the point like this:

Once you have this baseline, showing the reality of the most recent few months of work, it’s an excellent starting point to help get your Product Leaders and stakeholders to help adjust where to spend time, using the full context of what the team has to work with.

What should we try to spend more time doing? Is it OK to spend less time doing something else?

Decide on Future Allocations

By presenting the work the team does in this manner, you are elevating the conversation out of the weeds. If your stakeholders are regularly arm wrestling with your Product Manager over individual user stories and jockeying for better positions in your product backlog, it’s going to be hard to get anything done.

The goal for any team should be to communicate with stakeholders and leaders at a strategic level and create the space and establish trust so that the team can make decisions based on all of the inputs available in a way that attempts to satisfy all of the desired outcomes.

I like to imagine the metaphor of a big dashboard full of levers, buttons, and sliders that we can present to executives, leaders, and stakeholders to get them to express what they want from us at a higher level. Something like: “Do more of this and less of that next month” and build the space and the trust at the same time to allow the team to make the detailed decisions about HOW to implement those strategic plans at a detailed level.

One of the hardest things about agile is allowing teams to have that level of agency to make decisions and set priorities within their own domain of expertise. It is very hard for anyone to understand the full breadth of knowledge necessary to be able to make those decisions. Each of the stakeholders and even the individual leaders only have a piece of the puzzle. The whole team, centered around a Product Manager or Product Owner, can collectively make them however.

Having too many chefs in the kitchen is never a good idea.

So, whenever you can, pull your leaders and stakeholders out of the weeds and ask them what they want in business terms. Speak their language of desired outcomes. Understand their concerns in terms of relative priorities. Help them express what they want at that level by giving them the attack surface that makes sense. Ideally, there is a vision and strategy expressed in quarterly OKRs that will help remind the leaders of the strategic decisions that have already been made and guide the right decisions to help accomplish the needs of the business.

Our leaders and stakeholders are humans too. And all of us humans tend to chase a shiny penny from time to time.

When we ask leaders if they “want more of less of X vs. Y”, it’s easier for them to give us a response than to drag them into the weeds and expect them to absorb everything they need to know to make those very difficult decisions about how to prioritize a complex portfolio of decisions.

Assuming you can pull off this level of conversation with your stakeholders and leaders who influence your priorities, your team still has to apply this information in a meaningful way to adhere to the expressed priorities. And that is not trivial, but it should be a lot easier than dealing with a dozen stakeholders all telling you about their number one priorities and not understanding why you can’t get things done soon enough for them.

Over time, your team can reshape the portfolio of priorities represented in your pie chart in a way that better aligns with the collective priorities of the purpose behind your team. I hope these ideas give you a place to start to simplify the conversations around complex backlog prioritization.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the complexity of the agile universe into easy to understand and simple common sense.

Curious? Ask for a free consultation.

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an Agile Coach teaching you the behaviors behind the Agile Mindset, why the topics are important, and what you can start doing about it. It also includes Scrum Master and leadership tips, AI prompts to help you explore and dig deeper, and tons of recommended books, videos, and articles.

Paperback and Kindle Available on Amazon.