Product Backlog

In this episode of Definitely Maybe Agile, Peter Maddison and David Sharrock explore the nuances of product backlogs in agile environments. They discuss the tension between emergent backlogs and fixed feature sets, the importance of backlog management, and various prioritization techniques, including "buy a feature" and impact-effort matrices.

This week's takeaways:

• Separate tactical (near-term) and strategic backlogs to reduce psychological pressure and maintain focus - avoid creating extensive long-term backlogs that will likely become irrelevant.
• Stakeholder prioritization must be balanced with technical constraints and team capabilities - product owners should communicate changes in delivery order transparently to maintain trust.
• Regular backlog refinement should include archiving rejected items instead of deleting them, helping teams avoid repeatedly addressing the same requests while keeping the active backlog manageable.

Ready to scale your agile practices? Tune in to more episodes on your favorite platform.

Chapters

• 0:04 Navigating Agile Product Backlogs
• 11:31 Managing Backlog Prioritization and Dependencies
• 18:13 Managing Backlog Prioritization and Maintenance

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you doing?

Dave: 0:14

Good, we've got that funny pause while we decide who's going to kick things off. Great to catch up again. Always a pleasure, and I'm kind of looking forward to this sort of free rambling conversation around product backlogs, because it's one of those topics that everybody talks about and yet nobody goes into detail on.

Peter: 0:35

It's this, or I wonder about things like the space of product is somewhat fluffy and not always consistently defined. Let's say so. It can mean different things to different people.

Dave: 0:49

I think is one part Even worse than that. I think people can use it to achieve different ends, start playing around with it. I mean, the one thing that I'm seeing a lot and I'm sure you've bumped into this many times is the sort of this idea of an emergent backlog that's continuously changing conflicts pretty strongly. I always think of the Venn diagram, of an emergent backlog coupled with some sort of definition that says there are 612 features and those features are in the backlog. You've got to deliver all of them. They don't overlap. There's no overlap between a sort of a dynamic, emergent, organic backlog, which is the goal, against fixed features, fixed delivery expectations.

Peter: 1:32

Yeah, yeah, and I think some of that comes from. It might partly depend on what you're doing, but I think it does also depend if you're coming at something from either a fixed mindset or with a I already know what it is I want to do and I already know what order I want to do it in. And so then it's less of a backlog and more of a project plan, because that's essentially. These are the tasks in this order, let's do them.

Dave: 1:55

And of course I mean one of the things for us to uncover. There is the problem with or let me put it a different way, the purpose of this emergent organic backlog is to solve a particular problem, which is that customers don't necessarily take to what we give them immediately. Sometimes we give them a new feature and it doesn't quite land right. We may need to make modifications and tweak it and really understand user behavior and exactly how things are going to work. And in order for us to have that option to explore and to kind of fine tune so we maximize conversion or customer experience, whatever that might be we need to be able to add on and tweak and modify that backlog. So that conflicts directly with this idea of hey, we've got a fixed amount of features to deliver, let's just become that feature factory and get those out of the door.

Peter: 2:41

Right, exactly Because it's applying to the space where we're thinking of a product. We're often thinking of a digital product, but it doesn't have to be. And if it's a digital product, we may be building something new and learning as we go. And if we're learning as we go, we're going to need to modify what comes up next in response to what it is that we learn. So the backlog is going to be different.

Dave: 3:04

right, it's going to change, it's going to evolve right, so that kind of naturally brings us to the time horizon within which the backlog is relevant.

Peter: 3:13

Any thoughts on that?

Dave: 3:14

What do you see typically?

Peter: 3:16

I find that the I mean my general experience of working with these is that if you end up with a massively long backlog, then you've probably wasted an awful lot of time putting the, especially the last objects into it, because they're going to be not ever done.

Peter: 3:34

You're never going to get to them, so why bother going to the effort of creating all of those objects?

Peter: 3:38

And I've seen it where people have gone in and they've created three years worth of work and it's like 300 odd stories or features are created. And, even worse, then the project gets put on hold and they come back to it a year and a half later and then they go and look at them and the reason why is they actually try to start working through them and find out that they're all completely irrelevant Because the underlying systems that they were going to be built out onto have all changed or they've been modified, and this isn't the way to approach the problem. So, yeah, it just tends to cause problem. It also causes angst from the fact that if you're, if you have that massive, long list and people can start to go back and start looking through it and information can get lost in it and you and you're spending time on. It is there kind of sitting in the back of your mind all the time that there's this big, big, long list of things that I'm supposed to be doing and yeah, yeah I.

Dave: 4:30

I think this this brings us on to one really critical point, which is I there is there's a tactical backlog that is typically a couple of sprints worth. If you're using scrum, there's a few sprints worth of work, maybe four or five weeks worth of work, refined, prepped ready for the team. In that backlog, maybe a bit further out, if you've planned over a quarter, potentially, you've got a few kind of placeholders for some work that's still to be defined further down the line. But that's that tactical. This is what we're working on right now and this is what's coming up next. These are the where the conversations around refinement and so on happen. But but it's sort of a filtered aspect of the broader backlog and that broader backlog has things like well, all of the future hopes and wishes for the product in there and there. We need to filter those out. We need to be able to say we're not going to look at those right now.

Dave: 5:20

But you also need a place where you're keeping them. So whether it's a pre-backlog to the tactical backlog or as part of the same backlog and just filtered out, it really depends on the system you're using and so on. And I also mentioned that because there's stuff that we decide not to do and we don't actually want to delete those, we want to archive those because otherwise I keep deciding not to do the same thing over and over again because we can't go. You know what so-and-so. This business stakeholder keeps raising the same problem every three months or whatever it might be.

Peter: 5:52

Yes, yeah, there's this piece of if something doesn't meet the criteria we have for being something that we should look at doing, then we should just put it into the deep freeze of a backlog and never have to look at it again. So it's important to do this. It's very, very important to pick up the work, screw it up and throw it away, and even if you're just going to put it somewhere else for time being, for reasons that you might want to refer to at some time in the far distant future, there can be problems with that too, if you end up doing it too much and the far distant future, um that, there can be problems with that too. If you end up doing it too much and your far distant future becomes this void of nothingness but the uh, but the. It is very, very important to make sure that uh out, it's out of sight, out of mind, so that you're not now constantly going back and looking at it, yeah, we don't have that psychological pressure of how, when am I going to get to this?

Dave: 6:44

and so on.

Dave: 6:45

It needs to be something that we can separate out.

Dave: 6:48

I remember just one of the organizations, many years ago now, that I worked with, and there was a gap between what the product owner was communicating to their stakeholders and what the stakeholders were expecting. And that gap was, broadly speaking, the product owner team had decided they weren't going to do a bunch of things, but they didn't tell the stakeholders. And we had this wonderful I still remember it was like the wiki page basically ended up just saying all of the work requests the development team are not working on, and so we could point all of the stakeholders to this to say you've made a whole bunch of requests, but none of these are in scope right now. We're just not spending any time, so please stop asking. And that just elevated and just allowed us to focus the conversations where they needed to be focused and allowed us to kind of put aside all of this distraction and noise associated with things that people thought they might be getting but just was never in the sights of the product owner team at that time.

Peter: 7:47

Yeah, exactly, and it's such an important thing that people don't do. I think it's definitely worth mentioning. There is now this piece and I think we kind of touched on it a couple of times of that deciding then what goes into the tactical versus non-tactical backlog, what, what things do we decide that we are going to put to one side and not talk about anymore, and the understanding that, and having mechanisms in place to do it and different ways of basically prioritizing what's happening in the backlog, so that we've focused on the next most important thing.

Dave: 8:24

That's another key part of it Well, and we often kind of get around this problem by saying it's in the hands of the product owner, but that's only. I mean, a lot of product owners actually can't make those decisions without at least communicating them back out to stakeholders or, at the worst case, bringing the stakeholders together and saying, okay, you're going to get really upset if I just do this feature before that feature. So I need your input and you're going to help me decide what the order of um kind of delivery is going to be. So, depending again a little bit on this current state that the product owner is working in, the sort of environment they're working in, we definitely like there's, there's always some great and just lots of great tools for prioritizing backlogs and and getting those interesting conversations out of the out on the table have you got?

Dave: 9:12

any favorites that you work with a lot there yeah, they're one of my.

Peter: 9:16

My favorites, which I used quite recently, was the buyer feature, one which, uh, is a that's a fun one to do, especially with executives. Actually, we did it with a little pile of monopoly money.

Dave: 9:26

I was gonna say, yeah, he's handed out to people, and literally I I, yeah, I, I love all of the conversations that get had, the deals, the backroom deals which are done in front of everybody, so they're not even backroom deals, but yeah it's, that's a lot of fun. That one, I mean, I think. The other one, the risk value matrix of pure is it high value, low value? Is it high effort, low effort? Whether it's risk or effort, those are just so simple to immediately break down 5 or 10 or 15 different requests and start breaking them down into some pretty actionable results coming out of that. That always works well.

Peter: 10:04

One I liked from Steve Pereira's recent book at least this was where I saw it was doing that impact effort type matrix, but doing it by first taking and stacking the items by importance most importance down to least importance before moving them horizontally across on a like a feasibility line together. He did as importance feasibility, but you can obviously do that in impact effort or however you want to take your grid to be. But I thought it was a nice way of moving things into the different places relative to each other, cause I have seen where people struggle. If you just give them the grid, everything ends up in one place, yeah yeah, whereas if you force them to rank them first, they've got to be one above the other. Something has to be more important than the other. They can't all be at the top. Then get them to move them across. They have to be spread out across the grid.

Dave: 11:02

Yeah yeah. No, I think the whole idea of sort of stack ranking in some way so stack ranking, for example, in terms of importance or priority or whatever it is is something which so many stakeholders really don't like when you first introduce it, but it's such a powerful way of doing things for sure.

Peter: 11:22

Yeah Well, you're forcing people to make a decision and the reality is they want to keep their options completely open.

Dave: 11:31

Now this brings us to a really interesting question, which is I've got direction on the priority, the order of the work being delivered in a backlog. Is that what the product owner then takes to the team and does? This is the order we have to deliver it, or what are the options a product owner might have in terms of reordering things as they may need to do?

Peter: 11:52

well, it's, uh, there's going to be a piece of like. Is that the sole set of prioritization? Do they have other information? Is there other things that they can pull into that that are potentially going to color it? Ideally, they're going to bring that back and have that discussion with the stakeholders. The worst thing they could do is do that in secret, say, hey, I brought you all together for a few hours and we can figure out the priority, going to do things in this order and then go off and do them in a completely different order and not tell them. That would be an equally bad thing to do.

Peter: 12:19

There is also the. There's a matter of scale here too. You know the product sides, the features, tend to be bigger chunks of work that will be broken down by teams and typically and there that means that there is some flexibility in which parts of that get done, or how is that going to be implemented, or what does that potentially look like? Which gives? So there's the. There's some needs to be room to understand, like what is that going to be? And that's, I mean, that's another important part of it. Yeah, well, I mean, I think there's some needs to be room to understand like what is that going to be?

Dave: 12:49

and that's, I mean, that's another important part of it. Yeah, well, I mean, I think there's, um, there's dependencies between items in a backlog stories or product backlog items, whatever they are, and uh, those dependencies mean you often get kind of clumps of stories coming together so that we need four or five of them to be delivered together to have a meaningful deliverable. And whether that is four or five items, because they're on one system or another system or I've got to release them together, whatever that might be, there is a need to sort of groups those together and just make sure that packet of work goes through together for sure. Other things are availability of the team, right, so sometimes somebody is on vacation, you're gonna have to move it around, or I have a particular skill set that can only take on so many pieces of work within their area of expertise, which might slow down the delivery and allow other bits of work to be coming through.

Dave: 13:37

So I think this is this really interesting interplay between the team and the product owner. When you've got good rapport, they're really, you know, managing technical debt, managing conflicting information coming in which, as you, really you know managing technical debt, managing conflicting information coming in which, as you say, the stakeholders don't necessarily need to worry about. But we need to make it visible and communicate that back to the stakeholders to say this is why that feature you thought would be the first thing out of the door is actually going to be the third thing, because these other things are happening, and that one is is again, sometimes the that responsibility for ordering the backlog gets handed over to a team. Sometimes I've seen that where the team kind of comes in and says I feel like we can do this at this point and this or the other one, and I always think there's this you know, they're highly paid professionals most of the time and so it isn't really what they feel like is what's needed to be done.

Dave: 14:26

in the same way, if I'm working in a kitchen of a restaurant, I can't cook what I want to cook. I'm going to cook with a customer.

Peter: 14:32

Yes, and there's a, but there's also that occurs too where it's like well, you may want to do all of the changes on the front end, but the database changes need to happen first, or else we can't deploy the changes to the front end because we won't be able to reference database changes. There are ways around that, but just trying to think of a good example where, from a technical perspective, there may be a very, very, very good reason why you need to do things in a different order than was initially proposed, and it may be just simply more effective to do it that way and you may have a better outcome as a result. So you do have to listen to your technical people.

Dave: 15:09

Well, I like where you're going with this one, because I think now we have that really distinct.

Dave: 15:14

As work comes into the backlog, it's being ordered, prioritized, value is being estimated.

Dave: 15:20

However, that conversation is going with stakeholders and they're telling us this ideal order of delivery, let's call it that, or priority. Telling us this ideal order of delivery, let's call it that, or priority. Then, as the product owner is now eliciting some details, getting a little bit more okay, what does it really mean to deliver this? We're now ending up at that backlog refinement conversation and now that second layer of information is coming in who's available, what are the technical constraints or the dependencies between these pieces of work. So now, as that product owner is coming out of the backlog refinement, they've got a much clearer idea of what the order of work in the backlog is and, of course, it's been discussed, agreed sized with the development team as well. So now you're in a position, as you come between the backlog refinement and the sprint planning where the work's going to get picked up, there should be a backlog which is pretty well ordered, based on exactly what we were just saying technical constraints, availability, you know, skill set, constraints, whatever it might be, dates coming along.

Dave: 16:17

Of course, there's commitments which are have a hard date, there are commitments which have a softer date, and all of those bits and pieces that are coming together so that between backlog and refinement and sprint planning there's a really clear, ordered backlog with enough detail the team can look at that feel confident about what they're going to be picking up and working on.

Peter: 16:36

What about defects? How?

Dave: 16:37

do you fit the defects in, or when do you fit the defects in?

Peter: 16:40

Well, zero defects. I mean, we don't have defects.

Dave: 16:43

Okay, right, isn't that a? I love it. I love it. Yeah, and how often have you seen that?

Peter: 16:49

I've seen it set as an operating goal and generally if you've got a very highly effective team, it is possible to get there. But you need to be operating in a way that you've got very strong automated testing, you've got very clear understanding of making very small changes incrementally into the target system, that you've got all the right pieces in place to properly do releases into the target environment. All of those things need to be in place for you to even start to think about really operating that manner. But it is possible. It's usually more that. How much of the environment am I potentially likely to impact by the change I'm about to make?

Dave: 17:37

Yeah, but I totally agree and I think the only time I've really seen that be effective is on agile teams that have a lot of influence over the technical debt in their environment. So they're, like you said, strong engineering practices, really great suite of test automation and things like this, where they're really able to get to the point where they can capture any defects fast, fix them kind of pretty much in real time or within a sprint or two, as they're going through for sure in some cases.

Peter: 18:08

But otherwise you are going to need to deal with other forms of technical debt that come in too. I mean, that's really just the prioritization. We understand what is the nature of this. So I mean, if a defect is in production that's only just been discovered, then it's really just a feature of the product at this point, just been discovered. Then it's really just a feature of the product. At this point your ability to go back and fix it. It depends on the criticality of it. Is it something that's impacting users being able to interact with the system? There's a lot that comes into that, but there's understanding and appropriately prioritizing that alongside what else is in the backlog. I mean, if there's a defect that's caused a critical issue in production, then clearly that is the number one thing that you're going to fix. And who cares about the product backlog? Because if the system isn't available, yeah exactly.

Dave: 19:01

I'm less concerned about those things, mainly because there's contingency in the team's commitment to absorb those, depending on the organization.

Dave: 19:10

But I do think that the things like production issues or defects that the team wants to kind of take care of they're coming into that backlog in between that backlog refinement and sprint planning. Potentially Really the only teams that I've seen really able to take control of technical debt have been teams that have an allocation capacity allocated to technical debt. I mean any sort of negotiation to bring technical debt stories into a backlog invariably means that little bit of friction means they don't get the attention it needs.

Peter: 19:45

Yeah, I mean, I'm hoping. By this point I mean from a DevOps perspective. We would always describe it as keeping your kitchen clean is usually one of the favorite analogies, right? If you use all of your dishes and you never wash anything up, eventually you're not going to have anything to eat dinner off, because so you've got to clean the dishes, you've got to keep the kitchen clean, and so any effective team has to be allocating a part of their time to cleaning the dishes and maintaining the systems and ensuring the defects get addressed, because otherwise you are eventually going to hit a point where the kitchen becomes unusable Absolutely.

Dave: 20:23

And it's not that far away. I mean, it's a lot like our kitchens, right.

Peter: 20:37

It's not like six months, it's six weeks potentially, and you're already hitting it pretty fast new technical systems and how those systems are going to work and how to interact with them, and all of these different pieces as the systems themselves change. And this is true regardless of whether you're using a SaaS-based system or IaaS, or you're just doing bare metal deploys on a mainframe.

Dave: 21:00

I think you're raising a really interesting point because it's not really in the notes that we made for this one. But there is work in the backlog that I wouldn't expect really to have to size or discuss too much, and one of the examples is production issues and defects. We're not going to overthink those, we're just going to get them cleaned up and fixed.

Dave: 21:16

But another element is the learning, and whether it's a lunch and learn that the team puts in because they've just finished the solution design for a particular piece of work and they just want to share that across the team, or it's a little bit of extra work that the teams are going to do in terms of education and cross-pollination, for, you know, understanding the direction that a particular piece of work is going in or whatever it might be, but these are items that not necessarily going to see in the backlog but are part of that space that you create. Why why the audit backlog is so important? To allow a little bit of flex in that work, so that the team can adjust and they're not just held accountable to some sort of predetermined. You must hit this amount of work every single sprint because that's going to move a little bit, depending on some of these other things which are a little bit more amorphous around the site.

Peter: 22:02

Yeah, so we've covered a lot, I see, more than I thought we would actually, but so we've covered a lot more than I thought we would actually. It's an interesting topic.

Dave: 22:09

It's a simple one, but it has layers of nuance in there, right yes, for sure, and I think we took it from the beginning to the end.

Peter: 22:17

So how would you sum this up for our listeners?

Dave: 22:22

So there's a lot in here. Let me take a couple of things that really strike me as being kind of interesting about what we've talked about. One is the different type views of the backlog. So that tactical what are we working on in the near term versus longer term, and being able to differentiate between them. So you're not, you don't have that psychological pressure of amounting amount of work to do or whatever it might be. I think that's super important, because I see too many product owners and teams just live with this kind of complete mess and try and pull things out of it, and I don't think that's particularly effective.

Dave: 22:55

The other point that we talked about and I think we just touched on it very lightly, but is to do with the ordering of the backlog.

Dave: 23:03

So we talked about both stakeholder input in terms of what they wanted to see in that delivery, but we then also talked about both stakeholder input in terms of what they want to see in that delivery.

Dave: 23:08

But we then also talked about working with the development team and, again, not allowing the development team to just determine what they choose. But there's a sort of a middle ground there and the dependencies that you often have, and I see that one is really a major investment of time from the product owner. It's something they're continually trying to understand, because it's too tempting to say you know there's 27 related items. That probably isn't. There's probably five or six, and then you can fit something else in before you hit that. So that whole ordering connection, dependency, conversation is super important, I think, and then if I was to pick a third one, it was just what we were talking about the sort of the items that you might not expect necessarily or don't get tracked in a backlog, but could, such as you know, production issues and defects, the obvious ones, but also the learning, other aspects around that. There's a number of different things that you might see bubbling along in that backlog, whether it's technical debt or issues, production issues and so on, or learning opportunities, whatever it might be.

Peter: 24:06

Anything to add. I think one that you were just touching on there was around when you think about that ordering and stuff that we're going to put to one side. If we're going to put it to one side, don't spend a whole ton of time sizing it or defining it or doing anything with it other than putting it to one side. You shouldn't invest any more time in it than the minimum that is necessary. I think that's one point that is worth calling out when we talk about that. I think you covered most of the other key points there, the other concepts around. How do we prioritize buying a feature or impact effort graphs? We talked a little bit about that as well. I think that's thinking about what are the mechanisms you're going to use and ensuring that people are on board and bought into that and explaining it to them is a key part of that as well. Say, hey, this is how we prioritize here and helping people through that and understanding it.

Dave: 25:02

I might just add to what you're saying, because sometimes we forget about this. When we talked about it you mentioned by a feature and we were kind of joking about how much fun it can be. I think it's super important that product, that that backlog, management of the backlog, is not a chore. It's something which should lead to some really interesting conversations, a little bit of humor in there, a little bit of like pushing boundaries and all the rest of it, because it's sort of the core to how the product owner is able to get their work done and it should definitely not be, you know, heavy in order to try and get something done or agreed or worked through.

Peter: 25:39

Yeah, that sounds good. Well, thank you very much, as always, Dave. Interesting conversation I hope our listeners enjoyed. Don't forget to send us feedback at feedback at definitelymaybeagilecom and I look forward to next time. Excellent Thanks again, Peter. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.