Ask a Professional Scrum Trainer About Product Backlog Management - Todd Miller & Ryan Ripley

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. It is ever changing and requires a Product Owner to meticulously consider many options before ordering it.

In this recorded session of the Ask a Professional Scrum Trainer series, PSTs Todd Miller and Ryan Ripley answered your burning questions on the topic of Product Backlog Management. They answered questions like:

•  What would your advice be for a new Scrum Master for understanding backlog management?
•  What tips can you share on how to refine a Large PBI that is too large to fit within a Sprint?
•  What would be your advice if management doesn’t understand advantages of a single product backlog in setting when multiple teams are working together?
•  How do you prioritize and order the items in your Product Backlog to ensure maximum value for the product?
•  In your personal view: What is the optimal format for a Product Backlog refinement?

And many more!

Learn more about the Professional Scrum Product Backlog Management Skills training course.

 

Transcript

Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask professional scrum trainer series, where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning. Good afternoon. Good evening, wherever you're located welcome to today's Ask a professional scrum trainer webinar. And today we are focusing on the topic of product backlog management. And today we have Todd Miller and Brian Ripley, two of our professional scrum trainers. So welcome to you both and welcome audience. And let's get started because I think we're gonna get into some great questions here today. Very quickly about scrum.org. We are the home of Scrum. We were founded by Ken Schwimmer back in 2009. And we our mission is to help people and team solve complex problems. And we do that through our training, certification and ongoing learning focused around professional Scrum. We are very big proponents of continuing your learning. We have a lot of free resources on our website, like this session. And we hope that this session plays an important part in your learning journey. So with that, I will hand it over to Todd to introduce himself. And then Ryan.

Todd Miller: 1:39

Todd Miller, professional scrum trainer, almost eight years now. I can't really believe that, but that's about enough about me.

Ryan Ripley: 1:51

Yeah, hi, I'm Ryan, thanks for having us. We hope all of you have some great product backlog questions. They have been a PST for six or seven years, I'm a little behind. I'm not quite as old as Todd. So. But he gets to be the senior PST on this one. But we're excited to talk with all of you. And we hope you get a lot out of this. And Lindsey, thanks for hosting. And thanks for having us.

Lindsay Velecina: 2:14

Awesome. Okay, so let's get into questions. So this question comes from James, what would you advise? What would your advice be for a new scrum master with understanding backlog management?

Todd Miller: 2:32

Where you think Ryan would go first,

Ryan Ripley: 2:34

I'll go first. I think for a new scrum master, when it comes to thinking about backlog management, I think one of the initial thoughts needs to be partnership. This is something that you're going to partner and teach and mentor and train and work with a product owner on. And so a lot of product owners, they're going to be business analysts, initially, they're going to be product managers that may not be familiar with agility, they might have a varying background, they might be really great product people, but they may not have a full understanding of the product backlog. And so what you're initially like, if I'm a new scrum master, and I'm working with a new team, I'm probably helping to have that I'm working with that product or I'm partnering with with them to help them understand that you're creating a transparent vision of the future of the product that we need a product called to decompose into product backlog items that this product backlog will be the key communication tool between you and between the product owner and stakeholders between the product owner and developers, between you know all of the conversations around our product, whether it's in sprint planning, or sprint review, or everywhere in between is going to be centered on this artifact this product backlog. So I think initially, you're a partner, you're helping build this out, you're teaching and training on great ways to do that. But you're also saying, Look, this is a core piece for empiricism. And this is where a lot of good collaboration is going to happen. What do you think?

Todd Miller: 4:01

Yeah, I think what's what's been on my mind recently, just around product backlog management. So 100% Agree, Ryan, you know, you're in a partnership with your product owner. And one thing you have to be concerned of is and constantly question whether that product backlog is transparent. Just another thing from a tool perspective, because we get a lot of questions about tools is just because there's a feature in a tool doesn't mean you have to use it. A lot of what we oftentimes see is product backlogs that are over complex, because of all the features that tools give us and the tools box us into how to do product backlog management. So I think that's stressing the transparent product backlog angle with you and your product owner as a scrum master, really making sure that that is coming to fruition. And that you're you're you're you're helping as an enabler of that rather than just enabling all the features isn't a tool because we paid for them? So that's about it. For me. It's just been on my mind. overcomplicate complicated product backlogs because of our tools.

Ryan Ripley: 5:10

Wait, Todd, you don't like you don't like 107 required fields on a product backlog?

Todd Miller: 5:15

Yeah. 107 is a small number of comparisons on product backlog, switch seats.

Lindsay Velecina: 5:23

All right. Thank you both for that advice there. So this question comes from Marcus, what tips can you share on how to refine a large PBI that is too large to fit within a sprint?

Todd Miller: 5:39

Yeah. So I think that this might be that we were just talking about this yesterday, that decomposing product backlog items is an art form, right? And so the pneumonic, that bill we came up with quite some time ago, invest, right, I think still is applicable, depending on how you're doing your forecasting, and things like that to estimate the estimable thing. But invest is an act, pneumonic that Bill wakeskate came up with I being independent, and being negotiable, V being valuable, ie being estimable and T being testable. And so that's a pneumonic that you can kind of look at and see especially dependent, how can you break down that product backlog item into independent pieces that are still deliverable that still give value to your customer. But that pneumonic from Bill way has been around for quite some time, I think it really still works. And it's something that you just have to work on, it's not easy to break product backlog items down at first. But once you get it and you're get the art form of it, you can't forget it.

Ryan Ripley: 6:49

Yeah, and I think, you know, to go along with invest, which is a great way to, I mean, you can start challenging your PBIS if they're too big and ask questions about each section of invest. I also think there's a mindset component here, Todd, that, you know, work, there's a difference between slicing work and breaking it down. Breaking it down, assumes that all the components we break down are gonna get done. Well, we're slicing work, I think the mindset you got to take on is like a gold miner. You know, there's a lot of rocks and gravel and dirt that has to be sifted through before we get to the gold, which is what we want. So when you're slicing work, you're not keeping the rocks and the gravel in the dirt. Like when you're when you're mining, that stuff is discarded. Like we only want the gold. So you're slicing down to value in an effort to do the minimal but sufficient to meet the needs of that PBI or the problem you're solving. And so I think that mindset shift, along with, you know, Todd's thoughts on on, on the art of breaking down, that work through invest, I think those two things together can get you a very long way.

Lindsay Velecina: 7:59

Thanks. Great advice there. Thank you. All right, so so many questions, keep them coming. And if you had dropped questions into the chat, if you could please move them over to the q&a. That would be great. That is the best way to capture all the questions. There was a follow up question that came in Ryan, regarding when you were talking about product backlog management being a partnership with the product owner. The person had asked for some clarification on that, because they always felt like the product owner was solely responsible for product backlog management. So they want to know a little bit about that partnership.

Ryan Ripley: 8:39

No, I think, and that's a great follow up. I think that the product owners accountable for the product backlog does that but that doesn't mean that they're on their own. I think a scrum master is certainly accountable to support that product owner as they learn how to manage it to men by managing a product backlog creating product backlog items ordering them sizing. Hopefully developers are sizing but but taking that sizing into account as we look at, you know, roadmapping and all the things that a product owner needs to do with the product backlog. I definitely think the scrum master is a partner in that through the training, teaching and mentoring. I think developers are a partner in that as they size and decompose and and refine product backlog refinement is a is a is a team sport or it can be as well. And so this notion that product owner you go off and you do the product backlog and developers you go over here and do with all the code and Scrum Masters well, we don't really know what you do, but go and do your thing. That's just that's that's not going to work in today's world. We are collaboratively working together on all aspects of product delivery. And we are as a scrum team held accountable ultimately to get to done and so the partnerships and collaborative opportunities are endless in the in the scrum framework and that a scrum master and product owner are certainly going to be collaborative partners. as we build out, refine and improve our product backlogs.

Lindsay Velecina: 10:05

Great clarification there. Thank you, Ryan. Hope that was helpful. So this next question here from Victor, what would your advice be if management doesn't understand the advantages of a single product backlog and the setting when multiple teams are working together?

Todd Miller: 10:23

So multiple teams are working together on the same product, I'll just make that assumption. Well, I think it's no, this is probably a very simplistic example of it. But it's sort of like going to the grocery store with five lists, right? And you don't know which one to choose. So the, but the thing that comes to my mind, too, here is the the explicit order of a single product backlog. Now, there's different product backlog management tactics that you may have to take when you're in a more scaled environment. Right? I think levels of decomposition have worked for me in the past and that circumstance, but you're talking about a single ordered list, that means we're choosing to have one thing that is the most valuable. Another aspect of this to resonating from scrum guide. 2020 is we now have product goals. Right? So product goal, being a longer term objective from the scrum team, and have a single product backlog or small product goal with multiple teams working on it means we're getting more done faster, right. So you know, our good friend, Dan OIST, stop starting and start finishing with multiple product backlogs. Odds are you're not finishing and there's a lot of work in flight that teams don't know about. Let's get that one single concentrated list. Like we wouldn't go to the grocery store with five different lists and work from there. Right, you might need to take some different tactics for product backlog management. But in the end of the day, it's easier to make it transparent. We know what's the most valuable and everybody's on the same page.

Ryan Ripley: 11:53

Well, and to Todd's last point there everyone being on the same page, how do I as a product owner, effectively work with a stakeholder on discussing roadmaps, future vision, potential things that we can be working on, if there's five different lists, and we don't have them all, or we're not clear on where the overlaps are. And if we do not have that holistic list, you know, to that last point Todd was making, it becomes very difficult to keep to give a a clear, cohesive, accurate message to our stakeholders, to our customers to our users. And that can certainly lead to a wide array of problems from a stakeholder management perspective as well. So yeah, but I love that analogy. Todd, can you can you imagine going to the grocery store, the five lists, and all the things that my kids are texting me to get, and by the time you get home, you've forgotten 10 things and no one's happy. So

Todd Miller: 12:45

especially if you go hungry, and you just come back with all kinds of junk food,

Lindsay Velecina: 12:51

get hangry at the grocery store. All right. So thank you for that. So here is a question. How do you prioritize an order that items in your product backlog to ensure maximum value of the product?

Ryan Ripley: 13:09

I think about what's valuable. And I put those things first. And I know that's kind of a silly answer. But it's, you know, as a product owner, I'm continually Todd has this great quote that he talks about where the product owner, and I think we got he got this from some I don't Hill Hill attributed correctly, but the product owner is an opinion aggregator. And I think that might have come from Simon Reindl initially, but Todd has been pushing that really hard in our classes. And I think it's such a beautiful way to state it. You know, it's got all these ideas, all of these needs. But ultimately, the product owner has to sit down and take all of that user feedback, customer feedback, stakeholder feedback, developer feedback, all these different areas and aggregate that down into what is value. And when they decide, and they come up with this model or this idea or this understanding of what is valuable, then they can actually look at their product backlog and say, what is the minimum but sufficient and the most important things that we must do to achieve our sprint goal, and ultimately, our product goal? And just be laser focused and absolutely ruthless about doing just those things. And I think if they can get to that point, then that value maximization that's implied in the question or the tasks about in the question becomes possible. But if we're not there, we don't have those prior steps. Then that value maximization and the ordering and sizing and estimation, all that stuff is is it doesn't help you. And so I think that first step is be that opinion aggregator. Getting clear understanding what of what value means in your context. And then ruthless, ruthless, ruthlessly, pursue that value, and don't let anything else distract you. If you can get that part right. I think the recipe comes easy.

Todd Miller: 14:58

Yeah, just Add the we often talked about there being other factors involved in ordering a product backlog, maybe if there's dependencies, as Ryan said, size risk associated with it, I also think about how, and we actually have another webinar coming up in a couple weeks about how we can rate relate how we manage our product backlog to evidence based management. Because we're, hopefully our product backlog items are either trying to deliver something that is valuable to our current users or customers. Or maybe we're trying to deliver something that may be seen as valuable to new or potential customers. And so I think that depending on where you're trying to go into the market, that EBM could really help guide you with with how you want to answer. And so I think that that I've been thinking about that quite a bit recently about how EBM can really make your product backlog more transparent, and maybe give you ideas on how to order it. And maybe even have you convinced that you shouldn't be spending as much time in it, because everything you're doing is a guess it's a hypothesis of value. So I think I just said a lot there. But I'm just talking about what my mind is processing?

Ryan Ripley: 16:19

No, I think you said a lot of good stuff there, Todd. And I think one of the most important things that people should walk away from that, from this whole discussion with is everything on your product backlog as a guest until you deliver. So if you really want to be a value Maximizer make the smallest best possible deliver the smallest things that could possibly work and get that feedback rapidly so that you can validate that you're actually delivering value to somebody somewhere who's using your product or service. So I think that delivery piece that rapid delivery, rapid feedback is often missed as well. It's a great point.

Lindsay Velecina: 16:53

Awesome, thank you. That was really great. So this next question here. So what tips do you have for managing stakeholders when communicating the priority of the backlog items? And when they can expect outcomes for their area?

Todd Miller: 17:09

Hmm. Yeah, so usually when when you get this question, so just a story. I think my first time being a product owner, I was like, like 29. Right, working in a in a in an area where people had been in a company for a long time. And like, it can be contentious, I think, I think you just really need to be honest about it. Be transparent, make your product backlog transparent. That doesn't mean just send them in an Excel, but relate to what they're hoping to learn and hear about it. And one of the things that I find that people are not, we have to remember that not everybody knows or even cares about Scrum. Right. One of the things that they do know and care about oftentimes is money. So knowing how much a sprint costs, and then potentially relating that to some kind of forecasts on what's some particular features, something like that might cost is really good, powerful information that allows you to have deeper conversations. So when it comes to that, I don't think there's a perfect way to manage stakeholders know who they are, maybe categorize how close or how far you need to have them. Make sure they're in your sprint reviews, if they're somebody that is actively involved in what you're working on now, and know what a sprint costs, because that as a product owner is a sometimes the leverage that you need to get people to kind of back off to be to be quite frank.

Lindsay Velecina: 18:38

That's great advice there. Thank you. Todd, do you have anything to add Ryan?

Ryan Ripley: 18:43

No, I think Todd covered it. I mean, those are those are some great tips to go with. I think we're good.

Lindsay Velecina: 18:48

Awesome. All right, moving right along so many questions. Keep them coming, folks. These are these are great. So Hello, Tom Ryan, two questions in this one. Is it worth it to have PBI classifications? If yes, do you have any pattern or suggestions regarding PBI classifications, for example, stories, bugs, improvements, spikes?

Todd Miller: 19:15

So for that question, this is what I this is where like, I start to think a little bit about what we Kanban. Right. So defining work item types. I don't know that other common classifications but work item types. And I think it's worth defining those because ultimately, you want to try to have as many common attributes on your product backlog items as possible, because that creates simplicity in your product backlog. However, for a new feature, I don't think you need reproduction steps like you would a bug. Right. So I think it's totally a thing to do to classify what kind of the work work item types that you have. And then try to find common attributes and maybe there's more specific attributes that you have under Are those work item types?

Lindsay Velecina: 20:03

That's great. And Todd recently wrote a blog about product backlog, Item Attributes and going to drop that into the chat. Thank you, buddy. You're welcome. All right, so this question here and your personal view, what is the optimal format for product backlog refinement?

Ryan Ripley: 20:26

Um, whichever format that actually, first of all get you to do refinement during the sprint. So if you're actually doing refinement, that's a I think that's a win. And I, as far as formats go, you're asking questions about the PBIS you're making them smaller, you're ordering you're refining. Some teams like to have checklists. You know, there's, there's different schools of thought there. I think walking through, you know, Todd brought up invest from Bill Lake, like, why not just question interrogate every PBI according to the, you know, independent, negotiable, valuable, estimable, small and testable. If you walk through those on every PBI, and they meet those criteria, you've probably done a good job. And then if you're finding that that's not helping you adapt it a bit. So I think that, for me is a good way. And that's what we recommend in the new product backlog, the professional Scrum Product Backlog management skills courses, walkthrough and best as, as part of refinement, you know, and we have some other methods in there as well. But I think that could be just a great way to get started. And it's a low impact, easy way to get to get going. Do you think there Todd?

Todd Miller: 21:44

Yeah. I don't really have too much trust that.

Ryan Ripley: 21:48

You know, what can I you know, let me hop back in there. format, the format question. We see this in every scrum events and a lot of practices. Everyone wants to know, should we do a Harry Potter retrospective? Or a Star Wars? Where would the Star Trek be better? And, and, you know, personally, I prefer the Hobbit, but I mean, whatever, whatever you pick, but the substance of it often gets missed, and reviews get totally neglected. But in this case, with the refinement, you know, asking for format is great. But are you actually doing refinement? Or because the bottom line is it happens whether you like it or not. It's going to happen haphazardly during sprint planning, or it's going to happen in a controlled and planned way throughout your sprint. And I think that's something to look at. Formats important. But how we execute it, and when we make time for it. And whether or not we're consistent with it, I think ought to be primary levels of concern as well.

Lindsay Velecina: 22:49

Great, thank you. All right, this question. Alan here is looking for some advice, it seems on what he should be doing. So hi, guys, we lost our product owner. So the business analysts took over Pio responsibilities then lost a BA. And they were replaced with a junior ba so I found myself taking on a lot of the backlog management as a scrum master. Should I be scared? Are we the Titanic heading for the iceberg? Apologies if this question is a little too specific.

Todd Miller: 23:27

Yeah. Thanks for this specific question now. And so, and you're not the Titanic, everything's okay. What I what I what I will, this makes me think of several times that I've been a scrum master, for a product owner that had never been a product owner before. They've just worried me a little bit with the with the junior comment, just because the product owner really needs decision making authority. And so I would, I would really make sure that your organization is respecting the fact that that person is going to be making decisions about the product value based decisions. But I don't do this very much different than when I was a scrum master for a person that didn't even know what a product owner was. But they were anointed a product owner, whether from the business or from it and they didn't know, this is time. This is why you're busy as a scrum master and why you get a paycheck, right? Because you are going to have to step up, you are going to have to help them you're going to have to teach them, you may be having to do some of the stuff and show them while you're doing it. So and hopefully over time, you can make sure that they are growing in their ability to be accountable for value maximization. But I guess I'm just thinking back to the times where I was in those circumstances and it's not an overnight transition. It's really, you may find yourself doing some POS stuff, but make sure you're not just doing it and you're explaining it to the product owner and with the notion that eventually they'll take it over.

Lindsay Velecina: 24:58

That's great. Anything to add Ryan's?

Ryan Ripley: 25:02

Yeah, I would just add in, you know, I love everything that said there, it's so important to work with these people in the junior tag is kind of concerning. And I would look into all of those things and take care of that first. I also think it's really important to go find the person whose budget you're spending and get them involved. You know, there's always a product. Like there's never a situation where you don't have one, you may just have not followed the money farther far enough yet. Right? There's always someone's budget you're spending and get it, get a hold of them and say, Hey, we've got the seventh person in two weeks, as stepped into, tell us what to build. It's your money. Would you like to be the product owner here and help us out? Because it's your cash we're burning. And I think that following the money in that situation can also help get that authority granted, that Todd was talking about can help you connect with people in the business who understand the product and the needs a little better. And I think you can do a lot of good things for a team. Because at some point, the person whose budget you're spending will show up to a review, and want to know what they've gotten for all that money that's been burned.

Lindsay Velecina: 26:13

That makes a lot of sense. Thank you, Alan, for this question. I hope this helps. So this question here, so how do you balance immediate business needs against long term goals in the backlog? Up Todd, you're muted.

Todd Miller: 26:32

Yeah, evidence based management. So so the word goals in here is interesting, immediate, immediate business needs against the long term goals in the product backlog. So Scrum, Scrum. Now, since 2020, has two different goals horizons, your sprint goal, which is you know, 30 days or less, this is the commitment we're hoping to accomplish. And you have a product goal, which is a longer term commitment in the scrum team. This is not in the scrum guide. This is I would say like a Kata ism, my feeling about it is that product goal shouldn't be more than three to six months, even three months is really long. But what you have to weigh is if there's business objectives outside the realms of your goals, what's going on? Right? Is it really important work to do? That should be things that the product owner is consistently questioning? Is it something that can wait because anything that you do that's not related to your goals is to distraction against your goals? And so the thing that I like that EBM adds in into addition, EVM has three different levels of goals, right, you have strategic, which is a really longer term objective years, often, you have an intermediate goal, which you could you could potentially correlate to the product goal. So a near term objective, and then you have immediate tactical goals, which you could if you wanted to correlate to a sprint goal. And so the three different tiers of goals allows you the opportunity to ask yourself a question, is this related to our active goals? Very similar to a team that gets asked to put something new into their sprint backlog? Is this going to impact our ability to achieve this sprinkle? Or is it related to the sprint goal, you do the same thing as you put things in your product backlog as it relates to the product goal. And then hopefully, maybe you're checking out EBM and relating those product goals to your strategic goal. Anything else is a distraction focus, and I would question whether it's valid or not.

Lindsay Velecina: 28:26

Awesome, thank you. Anything to add, Ryan?

Ryan Ripley: 28:30

No, I think you'd be a great way to address the question indeed. So totally agree with Tom.

Lindsay Velecina: 28:38

Great. All right. So next question here from Ben, how do you handle constantly failing PBI estimations.

Ryan Ripley: 28:48

Um, I'm not so worried about estimates being right or wrong. And I'm not really worried about actual versus estimated, I think estimated versus actual is one of the worst metrics you can look at. I don't care if we're good estimators. I don't care if we're good at delivery. And so what I'm looking at, what I'm looking at is, are we achieving our sprint goal each and every sprint, not whether or not we could plan the perfect sprint, at the beginning of the sprint. I just I think that's such an important distinction. The sprint goal represents value. If we're achieving that sprint goal each and every sprint, we should be maximizing and achieving value through move them through that delivery and have an increment. Stop worrying about these scoreboard metrics. If you're delivering and hitting your sprint goals and delighting your customers, and getting that rapid feedback, you're winning. And that's what I would focus on. I just don't think trying to become the best estimators in the world lends itself to becoming free dead product of the brand think those two things are separate.

Todd Miller: 29:54

Yeah, you know, it's interesting and this can become controversial, but in a lot of instances, estimating is a waste of time. Why are you doing what I want to get to as the core of it? What Why are you estimating what are you trying to get out of it? What's the purpose of why you're estimating? You know, I think there's other things that we can use to bring into sprint planning to be a little bit smarter about capacity than just estimating things. And so I've really, I started thinking about that as it relates to EBM recently, and I almost see, I see estimating, taking time away from like you were saying, right, and delivery. So why are we estimate that? Like, let's start asking that question. Right, let's, where are we estimating what what value are we getting out of estimating? I know, there's cases where you have to be able to forecast. You have to be able to forecast maybe go to jail items, right, like compliancy stuff. But what else are we looking for? Are we are we looking to get certainty around delivery with that, because I think that the time that you're certain is when you're done, it's shipped, it's in the user hands and you're measuring the validity of it. That's that's where certainty is. And even past that, we're still not certain whether it was going to work or not. So I've been kind of questioning a lot of that in my brain a lot recently. And like, rather than push it off and say you shouldn't be estimating at all, what I'd like everybody to do is start questioning why. Why are we estimating? Or let's figure that out first? And then and then let's go from there. And a lot of instances, it's just because someone somewhere is craving, complete certainty when we're coping with complexity.

Ryan Ripley: 31:51

You know, something else to add there to link it back to a previous question. And of course, I agree with you that they're craving the certainty in a complex world. But teams would spend as much time studying, practicing and worrying about slicing, as they do estimation, the project, I believe the problem will take care of itself. Good at slicing, the estimates really don't be aren't so relevant. You can look at Cycle Time throughput, item aging, all all really good time to market measurements within EBM and the flow metrics. And if you get good at slicing, perhaps the estimates just become less and less important.

Lindsay Velecina: 32:33

That's great. And there are quite a few questions in here about slicing and breaking down items. So do you can you both share some of your favorite techniques for that?

Ryan Ripley: 32:48

So I like looking, so maybe I'm an old school nerd, I like looking at the database and seeing logically how data is sorted. And then seeing if there's ways to break down features or PBIS, based off of data patterns, or areas of concern in the database. I think that's one, one good way to look at it. I think workflows are another great place that I tend my brain will drift there as well. If there's, you know, some, there's some sequence in an in a processor practice, that might be a good place to look for, for areas to break down. And I think those can initially be helpful. But ultimately, what we're trying to do is get a good slice of, of a holistic feature. And again, to Todd's point, that's an art, you know, so you can look at data patterns, you can look at the workflow of a of a story or a feature of a PBI. But ultimately, we're mining for that slice of goodness, that can tell us whether or not this this hypothesis, this PBI is actually valued. I mean, those are my two, Todd, you got some you got some favorites that you like,

Todd Miller: 33:57

I just think there's different ways to look at a PBI and break it down. I think that a very popular is user story mapping, I think that you can even do impact mapping to give you some idea on how you can get a path to a very particular user, I think it's really important to know who your users are. Because you may we may have a product backlog that just says something is targeted towards a very specific user. Yeah, I see and chat to Henry put the spider in there, which is cool. But fingers like my comb thing, which works really well. But we need to understand our users because you might be targeting a really a general user base when you actually need to target a particular one. And I always think of the example and I don't remember where I saw it, but I think of why you would book a hotel room. So there's a difference between so a person booking a hotel room, right? That's one thing, but there is a difference between saying a father bringing kids to a hotel room that I want to book versus a business person Some that wants to book right. So very knowing who your user base is, and maybe categorizing some of your demographics so that you can specific, specifically target functionality tends to take that generis ism away from, from, from the user stories or product backlog items or drop stories are HDX, whatever you're using, and, and can make you specifically target things. That's also a valid for experiments, if you're looking at unrealized value or current value of a specific user that you're trying to get, or maybe a specific user that you already have you're trying to build upon. So you're all those, I think that we've just named a whole bunch of them, experiment with them, find what works for you today. But that is of no guarantee to work for you tomorrow, unfortunately.

Ryan Ripley: 35:49

You know, let's pull on that thread for just a quick second, right. I love the hotel booking example. So you've got people who walk up without a reservation and try to book people with the reservation to try to book you have frequent travelers like Todd at night used to be with a billion points who tried to show up and use points, people who show up and expect a free upgrade you have. I mean, you could probably if we worked at at least 100 different scenarios for cooking. And now as a product owner, you've got to pick which one makes the most sense to do first, which one can be the quickest to get out and getting experiments on in your playing all of these different decisions and different types of users, you're looking for biggest bang for the buck. But you're also looking for what we should quickly. And so all those considerations come in, I think, Todd, that's a wonderful example. And if people really pulled that thread of it, you'd start to see the type of user, that might be a really great place to start just because of even in a generic application. If I log in, and I'm user, my experience is going to be very different than an admin. And so maybe that's, I mean, that's a little too basic. But it's a good place to start thinking about ways to slice down and, and work through that. So I love that example.

Lindsay Velecina: 37:00

Great, thank you. All right. Hope that was helpful there. And there's a bunch of content on scrum veteran blog as well regarding slicing. So we, this question comes from Greg, he just dropped it in the chat. We want to help our product management folks give broad estimates and timeframes to upper management, though, we know that our own estimations are only really useful for current sprint, is there a good way to represent and measure past delivery? Other than playing with velocity calculations?

Todd Miller: 37:38

Yeah, um, so what did you deliver to production? Are customers satisfied with it? I think we need to move away. Ryan, I think you use the term like vanity metrics, right? Like so this is what we were kind of talking about before. So upper management wants that what's upper management want that for? What indicator is that giving them because we're maybe losing an opportunity to have a new conversation around what metrics we actually care about which what we should care about. And to me, delivering stuff to your customers that they use, and that they like with high quality in a timely manner is important. And you could have increasing velocity over the course of eight sprints and habit hadn't have not delivered anything. Right? You could have everybody 100% utilized and add capacity and your customers are leaving you in the droves. So I really like to kind of try to turn that conversation and say and get with those managers and say, what information are they looking for? And let's have a better conversation with them, rather than around these vanity, things like whether we estimated correctly, what's happening with story points and velocity, because at the end of the day, all that stuff could look really good. And your delivery engineers not delivering anything, it's failing. Right. So I think we I think we really need to start moving away from some of these things. I think there's really good answers. There's things we can use. I keep saying EVM because that is a great way to back into a new, better conversations, right, is through the discussions of goals and measurements and the key value areas. EVM What do you think, right?

Ryan Ripley: 39:22

Oh, you know, I totally agree. I think EBM changes the conversation. And I think we can check it out. There's a ton of great information that scrum.org/evm And Todd and I have EBM related materials on our YouTube channel. All sorts of great stuff out there. Actually, our new PPM book in the scrum.org series, I think will be out in a couple of weeks here. Lots of great materials coming up. But I also think plus, you know, just to put a big plus sign after EBM you know, if you're working with these executives, a trick I used to do is I would take a big printout of like the Doppler radar map, that I would just lay some PBIS on the map and say, Look, we're forecasting, you know, these are the goals, or these are the things we're trying to achieve. Now, these are the things that could be next. Here's the things that could be later. And just put in the context of the Doppler radar, because this is a forecast. Right? This is where really, you know, and I think Todd made this point very well earlier, trying to move away from this discussion of complexity, or this discussion of certainty income in the complex world. We're trying to we're like what works for us rather than perfect estimators, you know, we want people to understand, here's what we believe is true today, the wetter weather pattern might shift, new data might come in and new opportunity might emerge. And the second that happens, we'll update you. But everything we're talking about is subject to change, because the world's complex and wild and, and opportunities emerge. And if you don't strike when the iron is hot, you're missing. And I think that's the kind of conversations we need to have, instead of, well, my team can do 12 story points, every sprint. I think the first conversation the one that Todd is provoking with EBM is a lot richer than these story points, which are really just not really meaningful outside of a scrum. So let's make that shift. Let's get it EBM on top of the product backlog, I think is the killer combo that's going to emerge over the next few years here.

Lindsay Velecina: 41:29

Great, thank you. And we did get a couple of comments here in the chat. Thank you for bearing with us, everybody, Ryan at a last minute change in schedule. And that's why he's doing this from the car. And hopefully the audio is okay. And I just wanted to recognize that. So apologies for that. So moving right along. So judging by the fact that refinement can be a team effort, how can we engage the team in generating more insights to perform the refinement itself?

Todd Miller: 42:04

Yeah, so interesting, is make sure that that the right people were there. So we see this pattern where during refinement, there's this there's this issue of consensus and this constant consensus thing that comes up, consensus doesn't have to mean every single person is involved in it. And so I've oftentimes gone, I've oftentimes gone to performance sessions, where you see 10 people sitting in a room with three people talking, you know, make make refinement, and maybe you have a regular schedule for refinement and just decide last second, who should be there who could go or what potentially where we talking about. So I think that I think that might be an interesting to consider making sure that the right people are there and putting the onus back on to the team to do it. And maybe it doesn't have to be on a schedule. Maybe it's just something where the product owner earmarks and things that need to be refined during a sprint and the team does it just in time. So

Lindsay Velecina: 43:06

that's great. Thank you, Ryan, anything to add there?

Ryan Ripley: 43:09

No, I think that's great. I like it. Awesome.

Lindsay Velecina: 43:14

All right. So this is an interesting question, how can we efficiently manage a backlog that mostly consists in recurrent activities?

Ryan Ripley: 43:24

So I'm going to make an assumption on this one, I'm going to say the recurring activities are books. And if that's not the right context, I apologize. So but apart but this, this pattern comes up regularly, we get the same 20 things that pop up each and every sprint, and we're always firefighting and triage into they come in to our backlog and over and over and over. So proper product backlog management, I think would dictate that we get to the root source of these things that are recurring. And stop them actually create product backlog items that stop those things from occurring. And I think that's the step that a lot of teams, extra stuff that teams will take. And so I think that's really up to a product owner to say, Look, I know these things keep coming in over and over and over. Like, how can we invest in such a way that these things stop coming in, so that we can look at better, newer, more valuable opportunities instead of the same things? So I think that could be one way to tackle this question without a lot of context. But if it's some kind of other situation, definitely happy for a follow up. What do you think?

Todd Miller: 44:30

You got my head on bugs and and so here's, here's the situation and the way that I feel with bugs is, and I'm not sure where I got this advice, I got this advice. And it was really, really good advice to somebody when somebody gave me and I wish I knew who to attribute it to. So thank you if you're out there, or whoever's out there they gave me this is as a product owner, do not get into a position where you're managing bugs where you're a bug manager, deal with the bugs. What are them at the top, get rid of them. Bug happen, we're dealing with complex work, there's no reason to punish anybody for anything around that you want to know how many bugs you have, but do not become a bug manager. That's a waste of your time. Right? So order your bugs at the top and get rid of them. And so Ryan, you might have locked me in there the bug conversation, but product owners should not be bug managers. And so whoever, whoever gave me that advice was really awesome early on, when I had first become a product owner. And I've always thought about that ever since.

Ryan Ripley: 45:30

I think that the teacher manage product backlog.

Todd Miller: 45:34

Don't be a bug manager.

Ryan Ripley: 45:36

There you go. Don't be a bug manager. It feels like a conference talk. Let's work on that.

Lindsay Velecina: 45:43

Yeah, hopefully that helps some of the other questions that came in regarding bugs. So this next question from Steven here, as a PIO, I've noticed for myself and read on forums that the backlog can become quite extensive, where and when do I make a cut off and close? items we will not get around to? Or should I just ignore the list becoming longer and longer?

Ryan Ripley: 46:07

You should check it you know, you're not I'm sorry, to cut you off.

Todd Miller: 46:11

Oh, go ahead. It's good.

Ryan Ripley: 46:13

This second, you know that you're not going to do that work, delete it. And not a moment later. Right? the delete key is a product owners best friend when it comes to product backlog management. And quite honestly, if you're executing Scrum, well, if you're having great sprint reviews, and you're working with your stakeholders and your users, and you're getting the latest, greatest information, you're talking about the markets, the usage of the product, the budgets, the opportunities that competitors, and you're getting all that new information, and you're adding new PBIS to your product backlog during sprint review, because honestly, sprint review is really just another it's a it's a fancy way to do product backlog refinement, so you're getting new information that's happening. So many new ideas are coming in each and every sprint that your ideas on the product backlog that are already 368 months old, you're never gonna get to them. And they're just stressing you out. Because now you have to maintain them because their inventory instead of opportunities. And so I say be ruthless set a line. If something's older than and start start conservative. If and PBI is older than six months, it's gone. And you know what, if you accidentally cut a good idea or two, they will come back. Good ideas are like boomerangs and customer will link it right back atcha. The second it re emerges and not a lot is lost. If we don't do this, if we ignore the growing backlog, it turns into that ending scene of Raiders of the Lost Ark, that endless warehouse of artifacts and it's just it's just, it's anxiety provoking, I see a product backlog with 1000 items on it. I don't even know what you're trying to build. I can't understand where we're going. As a developer, you're you've put me on a treadmill. This is essential. The Delete key is essential, subtle line, start deleting good ideas. We'll come back, there'll be alright. What do you think

Todd Miller: 48:08

Ryan took on my punch lines.

Lindsay Velecina: 48:11

There were a lot of great punch lines. And there's

Todd Miller: 48:13

my here's two things, just to reiterate what Ryan said, set a limit on product backlog items. It doesn't have to be the date but say no more than 50 items in the product backlog. If you have 49 and you want to add a 50th or if you have 50 and one out of 51st Delete one if it was good. It'll come back.

Ryan Ripley: 48:30

Yeah, you know, they people treat these PBIS like they're their children. And I And it's almost like it's just when you say delete people get get panicky, I say be ruthless look. Something we talked about in the backlog management class is how ruthless Steve Jobs was with the first version of the iPhone. Todd, do you think Steve Jobs had 1000 items on his backbone for the first iPhone?

Todd Miller: 48:53

I don't know. I don't think he used to backlog, right?

Ryan Ripley: 48:56

Maybe. But I think there were some very key things that were important and everything else was negotiable. And I think that's the mindset we got to get into just this ruthless execution of Product Management. And the idea that we are going to do the minimal but sufficient. I love that mark, you set out of 50 items can get there that maybe it's the 50 PBI challenge. That's another t shirt.

Lindsay Velecina: 49:24

That was great. Lots of lots of T shirts in that answer. So that was awesome. I hope that helped. So this next question here, how do you challenge product backlog items that seem to be quick wins but introduce more technical debt?

Todd Miller: 49:41

Well, I mean, getting to know your technical debt landscape for that and also this is a this is a point in product, disappointment product kind of decision. So what I mean by that I was I was a product owner for a product that was only only capable Both for English. And there was a market opportunity if we added additional languages to it, which, which seems simple on the surface, but when it comes to how different countries other than the US use metric, rather than empirical and the number formatting it was, it actually was was was a really complex thing to implement. And there was a good way for us to do it. And there was a down and dirty way for us to do it. But we wanted to see if we could capitalize on the market. So we down and dirty to and just jammed it in with five different languages, knowing that we would have to go back and revisit it. But we wanted to test the validity of us getting in these other markets. And it was successful. And so knowing that it was successful, and having wanting us to expand to over 20 different languages, we went back in and we cleaned it up to be able to be capable for that. So I think it really comes down to the what's happening with your product. And if it's a point in time thing, because we consciously inherited technical debt, to prove that we can be successful in that market. And we were successful in that market. So we fix the technical that the thing is we fix it, we didn't just let it sit there. We didn't build upon it. We fixed it once we once we validated it. So I really think it depends on the point in your market. But make sure you're marking that stuff that you need to go back and fix. You've just deliberately chosen to take technical debt on. And you have to pay it back. So yeah, sorry, go.

Lindsay Velecina: 51:36

Awesome. Alright, so we have time for maybe one or two more questions here. We got a couple of follow up questions in that I thought were interesting. Going back to the recurring activities, where we kind of drilled in on bugs, someone asked if What if the product is consumer is customer relationship management software, and part of the recurring activities are things like creating email campaigns?

Ryan Ripley: 52:04

That seems like an ad. I mean, it seems like an activity that you're going to do. So if you're doing CRM, and part of it is it's emails and activity, then something that you could look at is automation, you know, as a product owner, are there, if there's 10 steps to getting that email Bill, can I use Zapier or, or some other tool to automate five of them away so that an email template with pre fed information is available and and I'm reducing the time spent? I think that's a good investment by a product owner. Sometimes there's just cost of doing business. There are things that Todd and I have to do to run our training company that I wish I could automate away, but I can't, you know, invoicing would be one of those topics. And so sometimes there's just activities that are gonna recur each and every sprint, but I think the the mindset here is challenged the assumptions. Do I have to do this email work? I have to do this email, where can I automate it? If I can't automate it? Why can't I? Is there are there investments I can make to free up this time. And I think if you've continued down that path of questioning, and not giving up after the first objection, or two, I still think you can make some good headway even for these repeatable activities that seem to be mandatory, but can often be reduced, perhaps not to zero, but perhaps to something smaller.

Lindsay Velecina: 53:24

That's great. Thank you. And we have one more follow up on the question about the product backlog getting too long and deleting items. So this question here, what should you do if you have a higher up to the scrum team like a VP that will not allow the PIO to delete items? And there was another question similar to that as well?

Todd Miller: 53:49

Yeah, I saw Kratos drop. What's interesting is it sounds to me like a PEO that is not empowered to be a product owner. It sounds like the VP really is the one making product decisions here. And so if the VP is not allowing a product owner to to actually be a product owner, this I think in turn becomes a scrum master problem, right? So you've got to meet with that VP. And you've got to, you've got to work with that VP on why it's important to empower a product owner to be a product owner. So again, Scrum Masters, this is where you earn your paycheck. What's the scrum master do all day deal with this kind of stuff? And ultimately, if a product owner isn't allowed to delete something off of their own product backlog, I can't think of a more miserable situation for me, right? Where I want to, I'm trying to be ruthless. I'm trying to keep that list small. I'm trying to understand it so that I can answer questions to it on the spot with really tough to deal with stakeholders. I'm trying to make it transparent. I'm trying to describe why I've ordered it the way that I've ordered it. The last thing I need is someone telling me that I can't delete something that isn't going to be done for 10 years or if ever, or that I don't find any value in just seems like an unempowered product owner problem and So I think Scrum Masters gotta get to work on this one.

Ryan Ripley: 55:05

That's something I used to do in this situation. And I'm sure, I'd certainly tell the story a billion times. So here's a billion in one for Todd. But I would just sit outside the VPS office every day. So this is me as a scrum master. I visit the VP every day with the product owner and say, Hey, this is what we intend to do, do you approve. And after the first three days, it's cute. After two or three weeks, the VP is annoyed. And then we kind of earned that right to have that conversation about empowerment. And I think that's one of the things as a great scrum master. That's back to the partnership and collaboration discussion. You know, a scrum master is a partner to that product owner that they're trying to get that product owner almost promoted to that level to where they have authority. And we will not tolerate anything less. And so we are pushing and striving to get that. Sometimes you got to walk through the big door and go talk to the VP has not mentioned, or visit them every day and get their opinion until they tell you, Hey, I'm too busy. And we we agree. So let's empower this person. Let's get rolling. And we don't give up. Like Scrum Masters, you've got to keep that conversation going all the time, and making sure that we are getting that product owner, the empowerment and respect and authority needed to be effective in their role.

Lindsay Velecina: 56:23

Yeah, that is super important. All right. So thank you both so much. You've shared some really great answers here and advice. We are running up on our time, unfortunately. But I will be sharing these questions with Ryan and Todd and we will figure out a way to address them in some format. Thank you so much to our audience. For your great questions. There were some really, really good questions that came in. I'm just going to close this out here with a few quick items. So we do have a new product backlog management course here@scrum.org, Todd and Ryan both teach it this, this quote here is from a student of theirs. So please feel free to check that out for more more learnings about product backlog management. And we also have free learning paths on our website and lots of content. So please feel free to check those out. And be sure to check out Ryan and Todd's YouTube channel as well agile for humans. And they always are putting out some great content there. Todd and Ryan, do you have any final words you want to leave with the audience?

Ryan Ripley: 57:40

Thank you. Thanks for having us. This is always fun. And Todd always enjoy bouncing this stuff up. And you and Lindsey. Thanks for putting up with our nonsense.

Todd Miller: 57:50

Oh, check out our EBM book coming out this series in a week.

Lindsay Velecina: 57:54

Yes, that is coming up very soon. You'll be seeing lots coming out from scrum.org about that as well. So thank you everybody, and Scrum on