Signs of Unhealthy Product Backlogs

Listen to Anthony Murphy, the founder of ProductPathways, as he goes through the top signs of an unhealthy product backlog.

Our guest

We’re talking to Anthony Murphy, a recognized Product Coach, writer, speaker, and the founder of ProductPathways, an online educational platform for Product Managers, Product Leaders, and teams that want to supercharge their product craft. Anthony shares the top signs of an unhealthy product backlog. Find out what they are and how to fix them.

Listen to this episode

Transcript

Gosia:  I’m here today with Anthony Murphy all the way from Australia. Anthony is a recognized product coach, writer, and speaker. He helps organizations build effective product teams. He is also the founder of Product Pathways, an online learning platform for product people. We will include the link in the description of this video if you would like to check out Anthony’s courses.

Anthony, hi. How are you? It’s nice to have you.

Anthony:  I’m really good. Thanks for having me.

Gosia:  Today, what we’re going to discuss is unhealthy product backlogs. Can you help our audience understand what are the signs of unhealthy product backlogs?

Anthony:  Yes. There’s a few signs. Probably the most common sign I see of an unhealthy backlog is when it becomes a dumping ground. This kind of breaks down to a few things, maybe I’ll try to decompose it. 

The first sign is it’s something that we just throw everything into. 

Gosia:  The list keeps growing and growing. It’s more than 100 items in the backlog. 

Anthony:  Exactly right. So, we’re not applying filters to say should this go on the backlog or not. Then, the worst part is that we don’t remove things. That’s probably another sign. When things aren’t being removed, it grows and it’s hundreds of items long, thousands of items long.

Gosia:  That’s very overwhelming having that huge backlog, like how to manage that. That’s a sign for teams, if they have a super long product backlog, that’s actually really not healthy.

Anthony:  I don’t think it’s healthy at all. I think backlogs should be short. If you think about it this way, if you’re trying to achieve a goal, and if you’re trying to be goal-centric, and even in the scrum guide they’ve brought in product goals and stuff. If you’re chasing a product goal, your backlog should be aligned to that goal. It should only be so long, because you’re trying to achieve that goal.

Anything that sits outside of it, maybe you want to keep it, but let’s put it somewhere else. Therefore, we keep it short, we keep it manageable. When it’s 1,000 items long, I don’t know who can manage that. I don’t think that’s possible.

Gosia:  That would give so many people a headache, I think. I don’t know. Over 100 items, that’s probably a sign that this is too long. Do you have a number that, for example, audits, if you work with an organization and you audit their backlog, you look at their product backlog, and you see a number, can you tell the people watching this video what number you would pick?

Anthony:  This is one of those how long is a piece of string type of questions. It’s a little difficult, but I’ll say one thing. If it’s in the hundreds, multiple hundreds, it’s definitely a smell and I’m going to want to investigate that. 

The reason why I’m hesitant about just saying a number is because it depends on what the items in your backlog are. I’ll give you an example. Is your backlog full of a whole bunch of bugs and really small level tasks and everything like that? Backlogs can grow quite quickly exponentially if as a team you decompose everything down to really small tasks. 

If you open up whatever backlog software you had, as an example, it was hundreds, but really maybe it’s a handful of large things, features, epics, whatever you want to call them. Maybe it’s only half a dozen of them and it’s just a whole bunch of really small tasks and bugs and all that type of stuff. Is the backlog too long or too big in that case? Probably not because we are still just very focused on a handful of things or less. 

Gosia:  Right. 

Anthony:  But if it was a mixture of 50 of those big things and 100 of the smaller things, and another 100 of the even smaller things, then now we’re starting to get into an issue. 

Gosia:  What are some other signs of unhealthy product backlogs? 

Anthony:  Kind of what I was talking about with different kinds of work and big items versus small items is probably another sign, which is it’s not organized. There are many different things that end up going into a backlog from really small bugs to opportunities and large items of work that we want to achieve. Unless we have a way to organize that and make sense of it, it’s really hard to manage.

This is probably something that maybe goes counter to some people’s beliefs, maybe it’s controversial. I don’t really believe in the notion of just having a linear backlog or even a single backlog. At least for me, practicing it, I’ve always found that hard to manage, particularly for mature and more complex products.

When you’re starting out with a new product and you’re a small team or a startup, sure, it’s fine. You can manage with a single linear backlog because you have very few items, very few things to worry about. 

But particularly in a mature product that’s in the market, many things are happening to it, it’s complex. You have bugs or enhancements on things that you built a year ago or two years ago, that type of stuff, and you’re trying to build new stuff, you’re trying to do stability enhancements. All of that becomes really hard to manage. 

My perspective is that you need a way to manage that. 

Gosia:  What’s the alternative to the linear backlog?

Anthony:  I think you need a way to manage it. There are multiple ways to do it. There are different formats. User story mapping is a good format that are fine for backlogs. Even something as simple as categories and classes of work. I’m going to have a backlog of defects, or even just be able to categorize inside my backlog that these are all defects, and then we can prioritize them, or enhancements, or stability things. 

Then you can compare apples to apples within that and you’re not trying to compare this small enhancement or this defect against some really large feature because, let’s be honest, that is not really a fair comparison. This is where prioritization frameworks also fall apart. If you did something like value over effort, you’re probably going to do all of the small enhancement stuff because it’s all value, low effort. All the big stuff is high value, high effort, so you just never touch them. 

Equally, if you used a formula like RICE or ICE, or any of those other prioritization frameworks, it’s hard to compare a new feature to a defect. The new feature is probably going to win in that case, as an example. So, categorization, applying different types of prioritization to them is necessary. Even, if you wanted to, split them into different backlogs. 

Possibly another sign of an unhealthy backlog is that backlogs only have features and new stuff to build as opposed to opportunities or things that we want to explore. Things that are really far in the future should just be an opportunity. We don’t know what we’re going to build yet, but this is a problem space or it’s a thing that we want to explore, and we should put it on the backlog. If a backlog doesn’t have that, it’s probably a good sign that you’re in a feature factory-type delivery mode, and that’s not necessarily a great backlog.

You could have an opportunity backlog, which is something that many people do. Dual Track Agile and Jeff Patton popularized a lot of this. An opportunity backlog, kind of a delivery backlog. I even kind of like having a backlog, per se, of the things that we’ve released, and going back and measuring those things.

Gosia:  Basically, not having one backlog. Can I ask you, I guess this is just my assumption, is it possible to do it just in Jira, or would you need any additional tools to really visualize it, especially if you put them in categories and having all of those different backlogs? 

Anthony:  It’s definitely achievable in Jira. I’ve done it. You’re not using things like components and labels, and those types of things. You can create different Agile board views inside Jira, so you’ll create a view for opportunities, etcetera. So, it is doable. I don’t find it as the easiest way to do it, because it’s a lot of admin overhead. 

If you can make it super visual and use a whiteboard tool, definitely that’s powerful. A physical board as well is always powerful, but I know we’re kind of digital nomads now.

Gosia:  To visualize it, it’s just easier. I think our brain processes it in a much easier way when we visualize things. 

Anthony:  Yes. I think the brain processing is a huge one, being able to split things and make sense of it in a certain way. 

I’ve done a lot of stuff like whiteboards and virtual whiteboard tools where we try the tree diagram type of things. All of this stuff links together and it makes a big tree diagram. That’s such a great sense-making tool. It’s like this makes sense now because this thing contributes to that thing, and that contributes to that thing, and that’s how we’re going to get this outcome for our goal at the top. All this work aligns to that goal. As opposed to in tools like Jira where it just kind of gets lost.

Gosia:  As opposed to, like you said, linear backlogs that are a list of 200 or 300 things. 

Anthony:  I have seen 1,000.

Gosia:  Super difficult to manage. I think we’re running out of time. Do you have one more tip for the signs of unhealthy product backlogs for our audience? 

Anthony:  Maybe the last one I would do is probably a tip about how to keep your backlog small. That is before you start to decompose the work, try to decompose the outcome. 

What I mean by that is sometimes we have a big outcome or goal that we want to achieve. Let’s say it’s something like increase conversion or something like that. Then we start to break down all of the work that we think we could do in order to achieve that goal. That is going to be a lot of things, potentially. What we can do, however, is to break that goal down first. 

If we want to increase conversion, let’s have a look at our conversion funnel, let’s have a look at the user flow, let’s have a look at all of that. What point inside this flow is the worst? How can we start there? Then instead of trying to improve conversion, you’re now trying to improve click-through rate or conversion on this part of the funnel, and the number of ideas and things that you can do around that is much smaller. When we fix that, we then move on to the next thing. Has that fixed conversion enough for us? If so, then move on to a new goal. If not, where is our next bottleneck? Let’s focus on that.

That’s just one example. You can kind of do that on anything. I often say teams don’t spend enough time slicing down the outcome and decomposing that. We kind of take it and then we jump to the work and try to decompose the work. That is also a way that we end up having a lot of backlog items. I don’t think it’s the most effective way, either. I think let’s slice down the outcome and break that down, and then align the work to it. Then we’ll always have small work, small backlog.

Gosia:  That’s so smart, actually. That’s very efficient. If we know that conversion is low, then really focusing on which part of that is contributing the most to that low conversion, and just focus on that one thing. That’s such great advice. Thank you.

Thanks so much, Anthony, for joining. Thanks, everyone, for watching this episode of The Agile On Board Show. Check out our YouTube channel and our previous episodes. Take care. Bye.