Backlog management is supposed to be simple, but the reality is different. Often, the backlog becomes a disguise for a waterfall framework.

The more items you have in your backlog, the more distant to agile you are.

The less goal-oriented your backlog is, the more fragmented your team becomes.

The more you focus on backlog management, the less you can discover value drivers.

Unfortunately, the backlog quickly deviates from a vehicle to create value to a distraction from what truly matters.

With extensive product backlog:

• Product managers become backlog managers
• Software engineers descend to coders
• Product designers derail to pixel-perfect designers
• Agile coaches become Agile rules

None of the above smells good. It stinks, and it stinks pretty bad.

Shall we defeat the backlog management traps?

Offer to you: If you’re tired of bullshit, welcome to my club. I can help you become an anti-bs product manager. Check out my self-paced course: Anti-Bullshit Product Management.

The Product Backlog Health Check

Understanding the status quo is fundamental to transforming it. Please take a few minutes to reflect on the following questions:

• Do your backlog items live forever, or do you dare to delete outdated ones?
• Are your backlog items unrelated, or are most related to an overarching goal?
• Does the size of your backlog scare you, or does it encourage you to discover the future and gradually bring new items?
• When you look at your backlog, do you get confused, or can you quickly glimpse where you are going?
• Are your backlog items related to fulfilling requirements or context to solving problems?

Take your time. Don’t rush. The more your answers are to the left, the more trapped you are in outdated backlog management. No worries! You’re not alone. I’ve been; it’s not funny.

Use the following Health Check to assess the sustainability of your product backlog. Do this with your team, share the results with your leadership, and then change one item at a time.

Product Backlog Health Check by David Pereira

Now, let me help you understand how to address each item of this health check and why it matters. I assume you may be skeptical and have some questions challenging me. Here are some examples:

• Why should I add a due date when I can put the irrelevant items at the bottom? You can do that, but you will get trapped in the past. Only when the old goes away does the new find its space. Trust me, whatever matters will come back to you.
• I have too many stakeholders, which makes it impossible to have an overarching goal. That’s a potential situation, and falling prey to that will ensure teams have to divide and conquer, leaving little chance to benefit from solid collaboration. The more context you switch, the less productive you become.
• Everyone has access to the backlog. How can I keep it organized? It’s fine to make the backlog available to your organization. Yet, it’s your responsibility to manage in a way that fosters collaboration. I will help you with that.
• Software engineers want requirements, not problems. If you want to limit them to coders, then give them requirements. Yet, you won’t get the best out of them. If you're going to benefit from creativity and outstanding solutions truly. Lead by context, not control.

Now, let me help you understand the essence of each health check item.

Due Date: Creating Space for Leaning

Which sentence would best describe backlog items?

1. The older it gets, the better it becomes
2. The older it gets, the less relevant it becomes

What’s your take?

We can agree that backlog items become obsolete as the context changes. Once the product grows, some things no longer make sense. Some bugs are not reproducible, and customers care about other things, which you have hopefully discovered.

Writing several backlog items that will never become features in your product is normal. Being Agile means learning what matters, focusing on it, and moving on.

It’s not okay to keep outdated items in your backlog to please stakeholders and let them “know” you will eventually deliver them. The more obsolete items you have, the more nonsense conversations you will have.

Keep the Product Backlog clean. Backlog items age like milk, not like wine

Agile Product Manifesto

Backlog Item Age by David Pereira

Treating your backlog items like wine creates confusion. You end up talking about irrelevant things, distracting you from what truly matters. Yet, when your backlog items age like milk, you will find space to address learnings and progress in a more promising direction.

Don’t let the past block your learning. Instead of increasing the size of your backlog, increase the size of your trash bin.

The practice I recommend is setting a due date for backlog items:

• 3 to 6 months due date. Depending on your scenario, backlog items will rot faster. It depends on your learning speed. Once the backlog reaches its due date, it’s good to go.
• Delete rotten items. Would you keep spoiled milk in your fridge? I don’t think so because it stinks. Would you drink spoiled milk? Unless you want to get sick, you won’t. Don’t be afraid to remove backlog items that don’t make it to a Sprint before their due date. Be afraid of keeping outdated backlog items that go into Sprint and block you from addressing your discoveries.

Setting a due date is unconventional. It’s no mystery that too many teams become feature factories.

Goal Related: Enabling the Power of Collaboration

What would you reach when you deliver on most of your backlog items?

1. Most business stakeholders would be pleased
2. An important outcome would be delivered

Option one is the most common, as the product backlog tends to reflect the wishes of business stakeholders. Now, let me tell you something rather obvious but often ignored: The wants of business stakeholders don’t always match customers’ needs.

The second option is the most adequate as it means alignment. Teams agree on goals and achieve results that drive the business forward while delighting customers.

It’s not about pleasing business stakeholders. It’s about uncovering what drives value for the business and customers and then delivering on that. Yet, for that, you need space. In other words, you need a goal to pursue instead of a list of tasks to deliver.

When teams lack a shared goal, everything is arguably a priority. Ultimately, every request becomes a backlog item. To break free from this trap, teams need to have a goal.

I like using Product Goals as the Scrum Guide suggests:

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

Regardless if you work with Scrum, that can be helpful. You may say we already have our vision; why would we need product goals? Simple, to be an intermediary step to be closer to your vision. Let me give you an example of one place I worked for:

• Vision: Spread wine love and culture throughout South America
• Product Goal: Excite new customers to explore the wine culture
• Sprint Goal: Tasty meal for everyone! Customers can find wine options that fit what they want to read.

When you break it down, the vision is achievable in five to ten years, while the product goal would take a few months or maybe a quarter, and the Sprint goal is just the size of your development cycle.

When you have a product goal, you can:

• Protect your backlog from cluttering with everything
• Align with business stakeholders on how to achieve the goal instead of gathering their wishes
• Use the product goal as a shield to say no by asking, “How would your request get us closer to our product goal?”

Having around 70–80% of your backlog related to the product goal is healthy. The remaining will probably relate to keeping the lights on (KTLO) work, like fixing bugs and technical and usability debt.

Again, the organization will resist committing to a single goal. Failing to do that will inevitably stretch teams thin and cause them to:

• Divide and conquer to deliver multiple goals
• Coordinate tasks instead of collaborating on goals
• Be unproductive as they continuously switch context

Focus on multiple goals if you want mediocre results. Commit to one goal at a time to achieve excellent results.

Lean Backlog: Avoiding Distractions

How do you maintain your product backlog? Common strategies are:

• Any request becomes a backlog item
• Once in, never out
• Focus on the past instead of the future

Classic backlog management will lead to a monstrous list of everything. Teams become executors instead of achievers. Beyond being no fun to work this way, teams have their potential limited by a long and distracting backlog.

It’s normal for product teams to exchange information with different business stakeholders and customers. Loads of requests will inevitably come your way as you talk to people. The classic approach leads to unnecessary pressure and lack of focus:

• New requests become backlog items
• New requests go to the top of the backlog
• Old requests to the bottom
• The backlog size only increases

If you want to renounce fun at work and chances of delivering higher value, follow the above.

Classic backlog management

Now, let me give you a way out.

Prioritize learning instead of cultivating a wish list.

Instead of mindlessly populating your backlog and endlessly increasing its size. Do the following:

• Reflect on how new items contribute to your overarching goal
• Only add items contributing to your priority
• New items in, old items out
• Keep your backlog size as lean as possible

A lean backlog management gives you space to explore the future openly. When you talk to business people and customers, you strive to learn what would drive value without thinking about your backlog. The backlog should be a vehicle to drive value, not a massive list to distract and pressure you.

Lean backlog management

I know you have unlimited space in your Jira, Asana, Trello, or whatever else you have. Yet, the tool should help you, not distract you from what matters.

If removing backlog items frightens you, just archive them. It’s essential to get them out of everyone else’s view so you can discuss the learnings instead of old promises. Keeping old promises in the backlog will waste time discussing what doesn’t matter. I don’t think you want that.

Organization: Simplifying What Others Complicate

When you look at your product backlog, how long does it take to get a glimpse of what you’re after?

If it takes more than a minute, your structure will probably be more complicated than it should be.

I noticed a few anomalies in the product backlog that got in the way of keeping it simple. Let me share them with you.

1. Definitions of Ready (DoR)

If you use DoR, stop using it and thank me later.

DoR hurts collaboration. Curiously, contrary to what the Agile Manifesto suggests, teams pay more attention to the process than individuals and interactions.

I did work with DoR, and I used to love it, but I had to kill it. DoR forced me to meet guidelines instead of collaborating with the team. Here are a few examples:

• Each backlog item has a minimum of 5 acceptance criteria. I had to write disguised requirements instead of talking to the team and sharing context.
• Backlog items must use the User Story format. There I was, trying to fit some opportunities into the User Story format instead of exploring the problem space with the team.
• Only estimated stories can be part of the Sprint. What if something relevant came up? I had to wait until the next iteration instead of addressing immediately. The goal should be to drive value instead of following processes.

The DoR may seem excellent at first glance, but don’t let that fool you. Instead of introducing processes, focus on improving collaboration.

2. User Story Obsession

Before User Stories, the business analysts wrote extensive specifications. I did that several times. The challenge is that too much speculation was added before getting hands-on. After User Stories, specs lost relevance, and more collaboration took place. Yet, somehow, a particular obsession took over. Let’s clarify a few aspects.

• It’s not mandatory. You don’t have to work with User Stories to be Agile. You could use them when you benefit from them, but that’s your choice. Alternatively, you can use a Job Story or a simple context description of what you’re trying to solve.
• It’s about the USER. For god sake, don’t write, “As a PM, I want,” “As Developers, we want,” or “As the Front-End, I want.” I thought the name was clear enough, but some weird mutations are more often than expected. When using User Stories, write it from the user’s perspective.
• It’s not about solutions. The user doesn’t want “Social Login”; the user wants to protect data, avoid creating another credential, or even experiment with the product before signing up. When you write User Stories related to solutions, the team is limited to implementing what’s written instead of exploring different solutions for the opportunity.
• It’s not for everything. Writing bugs, tech debts, and refactoring as User Stories reflect a considerable waste. Keep it as simple as possible. User Stories don’t reflect the best format for each backlog item. Use it when it makes sense, and avoid it when it looks off.
• Disguised specs. When PMs write several User Stories, including acceptance criteria, and then ask teams to estimate, they miss the mark. User Stories are about fostering collaboration and building shared understanding, not throwing requirements over the fence.

Apply User Stories when it helps you build shared understanding. Please don’t force it when it doesn’t contribute to that.

To conclude this part, look at the following image. What do you see?

Sometimes, I look at the team backlog and quickly become overwhelmed by loaded titles written as User Stories. Keep the title as simple as possible. The backlog should give you a high-level idea of where the team is going.

3. Disguised Project Management

Do you pre-plan sprints?

I’ve seen some backlogs with a few Sprints ahead, clarifying what happens when. Sometimes, that gets plotted in a beautiful Gantt chart so everyone understands what’s the team after.

Wait a minute, are we talking about agility or project management?

It’s fine to have a view of the future. It’s not fine to pre-plan sprints and create considerable output expectations because that removes flexibility.

What happens when teams realize their current direction becomes obsolete? The proper course of action is to adapt the backlog and move on. Yet, with pre-planned sprints, the plan quickly becomes the goal, distracting teams from doing what they should be doing and blocking them from delivering value faster.

I discourage teams from pre-planning sprints. I encourage teams to remain focused on learning and continuously correct courses as they uncover what matters.

Focus on Learning: Leading by Context, Not Control

Creating digital products is teamwork, not one person’s show.

Product managers should not:

• Give wireframes to designers so they can create high-fidelity prototypes, but which problems are worth solving
• Define solutions and ask software engineers to implement them, but share the context and problem space so the team crafts a solution
• Sign off solutions so they can go live, but collaborate with the team and craft solutions they are proud off

The above represents how product managers should collaborate with other team members. Unfortunately, that’s often not the case. The reasons vary, but it turns out that product managers will face a few hurdles on the way. Let me name a few:

• Software engineers are reluctant to craft solutions as they are paid to code. When that happens, get closer to the Tech Lead and strive to try something differently, at least partly so the team can get used to that.
• Designers are inexperienced with user research. Often, teams lack a person specialist with user experience, which is a considerable problem. How can someone design something without understanding the user? I asked myself this question some time ago, leading me to leave my comfort zone. I worked with a designer to interview customers, test wireframes, and evaluate how they reacted. None of us were specialists in user experience, but we did what we could to drop bad ideas before getting them into the product.
• Stakeholders call the shots. Results are endangered when business people drive product decisions and limit customer contact. A way out is to get them to see what you see. Probably many features are useless and have no value; help them see that and ask if that’s what they want. Within that, you can bring new ways of working.

Leading by context means renouncing command and control and trusting team members to decide what makes sense and what doesn’t. That entails writing context-oriented backlog items instead of solution-driven ones. Also, it means exploring the problem space before designing solutions.

Understanding the problem over thinking of solutions

Agile Product Manifesto

Simplifying Product Backlog Management

Alright! You went through the health check and improved your product backlog, which now shines like a diamond. How do you keep it clean?

Use Marie Kondo’s strategy. Keep it simple, and continuously remove the excess.

I like saying that the product backlog is the home of your product. How do you treat your home? You have different levels of cleaning, which are:

1. Daily cleaning. Every day, you do basic cleaning, e.g., making the bed, cleaning the toilet after yourself, watching the dishes after using them, etc. You do that so your home doesn’t become a mess.
2. Frequent cleaning. Maybe once or twice a week, you take cleaning more seriously. You remove the dust, wipe the floors, wash the windows, etc., so your home still has good air to breathe and is cozy.
3. Special moments. On a few occasions, you take cleaning to a different level. You clean places you barely see, organize things for hours, throw away unused objects, etc. You may do that because you have a special dinner at home or your mom is coming, and you don’t want her telling you how “dirty” your home is.

Three simple cleaning levels so your home remains pleasant enough. Now, let me ask you a question. What would happen if you stopped the daily cleaning? What if you didn’t remove the dust for a few weeks? It wouldn’t take longer to make your home so unpleasant that you don’t want to be there.

Now, apply the same thought to the backlog. If you stop cleaning it, you let it be. What would happen? It would probably be something you despise. That’s not what we want.

Let me give you my Extreme Backlog Cleaning Routine.

1. Weekly — Remove the Old. Once a week, you take a moment to declutter your Product Backlog. Identify all items untouched over the last three months and remove them. If you’re radical like me, delete them. Otherwise, archiving them would be good enough.
2. Bi-weekly — Keep the Goal Alive. Product backlog items should relate to an overarching goal. If they don’t, you’re getting distracted from what matters most. Every second week, go through your backlog items and remove everything unrelated to the goal you’re pursuing now.
3. Monthly — Keep it Beautiful. The backlog is your product’s home, so make it so beautiful that you’re proud of it, and work becomes pleasant. Once a month, do the following:
4. Give a home to your items by assigning epics to them
5. Make it easy to read by simplifying the title of your items (User Story isn’t a title)
6. Remove or add information to placeholders. Don’t keep them distracting you

To conclude this episode, I leave you with a quote from Mike Cohn, co-founder of Agile Alliance and author of multiple books.

Mike Cohn on Product Backlog

Written by David Pereira