AA102 - Backlog Anti-Patterns

It's the Arguing Agile podcast on the arguing Agile channel. Introductions aside, I wanted to talk about anti patterns in dealing with the product backlog and in the way you do refinements. We're gonna look at a, a, a list and see if we agree or disagree with them. Sounds good. And then here we go. Product backlog and refinement, anti pattern. One, I, I don't know if that was like, because somebody saved it twice over the same file and it got . I'm hoping that's, this is part one of several. It might be. Yeah. I don't know. Anyway, let's go to the first bullet point. Prioritization by proxy. A single stakeholder or a committee of stakeholders prioritizes the backlog. This is supposed to be an anti-pain, right? Antipater Single stakeholder or a committee. Yeah, well look a committee, definitely, because a, committee of stakeholders, Prioritizing the backlog might be a recipe for disaster because you've got people with their own vested interests in what they want out of the product. They're gonna be prioritizing the backlog from their own lens. Right. Which, which is not gonna be a singular representation of the backlog to the team. Yeah. So that might be an issue. A single person, I don't necessarily have a problem with that. Honestly. Uh, you know, I, I think as long as that person is the right person who understands the product and what needs to be delivered and why? Everyone listening to this is like, oh, a committee doing prioritization, that sounds terrible. Okay, well let's, let's delete that out of. Just for the purpose of furthering discussion, let's just say a single stakeholder prioritizes the product backlog. single stakeholder, meaning someone who is not the product owner slash product manager, that's a problem. Oh, yeah. If that's what it means there, then I agree. I had assumed that that would be the person who, like I said, who understands the, you know, the what and the why. That would be the product owner. Mm-hmm. if that is not that person, you've got the same problem you have with a committee, only with one person now. Prioritizing backlog from their perspective and only from their perspective. I guess it's not a committee cuz it's one person's job. It's a product owner's job. Like if we're going to go with the scrum guide and scrum roles, right. Product manager. Just so I don't have to keep you saying like, product owner, product manager, et cetera, et cetera. If the product owner is the person who is empowered with, prioritization over the backlog, the committee of stakeholders, other single stakeholders who have a big say in the matter or whatever, isn't your job at that point managing all these stakeholders? Let's pretend for a second that the, the what the bullet point of a single stakeholder or committee of stakeholders prioritizes the product backlog. Let's pretend for a second that the intention of that bullet point means. M in my organization I normally have, some very powerful political entities or one individual who can kind of undermine what I'm doing with, with respect to the direction vision of the product, you know what I mean? Which I translate directly in a backlog. Here's the great argument for someone might, maybe working and maybe stuck behind an issue like this. If you're in a small company, maybe you're the first person they hired to be the product manager and that single stake. Is the ceo, right? Especially in that phase where you're trying to separate from the ceo, all of the main product prioritization kind of decisions because they've just hired you as a product manager for the first time, for example. What that single stakeholder says is really important and you do need to serve them. So, uh, like on is that so bad that, you know, you have one single person who maybe they don't demand stuff all the time, but like when they do come calling, you know, you kind of politically inside. You know, inside baseball kind of knowing, you know, that you just kind of have to have to do whatever they say and then move on. Yeah. I think you, you make a, a point there. So in that scenario, absolutely right. You, you're gonna be subservient to that person. hopefully, maybe they're, they're not the ones that are in the backlog with their sleeve rolled up. You are working with them, which means you as in the product owner, product person, you would have visibility into what else is in there. Yeah. What are the dependencies? They may not care, they may not even be aware of them. That they may just, that's true. Should come in and say, I need this, I need this, I need this. Right. So you'd be able to advise them and say, in order to do that, we have to do this here first. I mean, we can do that in the next sprint or the sprint after. So you can moderate the discussion and kind of, you can still manage the backlog. Yes. You're gonna be driven by their requirements for sure. Yeah. Um, in that scenario where, you know, they are the, the person. basically funding, funding the teams effectively. They're the, they're the sponsor. The primary stakeholder, fine.. I think still at the end of the day, prioritizing the backlog is upon, is is incumbent upon the person who understands the periphery of what is going on. Yeah. Not just that one item or Yeah. Those specific items. When you were dealing with stakeholder communication, by proxy means you're basically stepping outta the way and let somebody else do the job and like you're not, you know, checking in and you're. Kind of, carrying along other people's wishes or whatever. You're kind of like stepping outta the way. I don't, I don't know. If the product person is not like it, it is kind of, surrendering the role. yeah. Kind of like the relinquishing the role. Yeah. Right. Yeah. Like, okay, you know, fine, you do it right. Yeah. You're right. The, the proxy part is what you're getting at, I think. Yeah. Yes. Because the person that you are, you are deferring that. Responsibility too, may not be a product oriented person in the sense that they may not realize all the dependencies, et cetera, let alone things like a roadmap. And you're working toward a roadmap. Somebody comes in and says, okay, now we're gonna do this. And you just step out of the way and say, fine. Go with it. Yeah. What does that mean? Yeah. To your overall plan. Right, right. Overall roadmap. Yeah. And this is the reason that I, uh, kind of, uh, advise people to have in their, in their corporate level, uh, kanban board, telling them what they're chewing through in their roadmap and kind of what they're involved in. I, I want that Expeditor lane to be shown to the executive so that when something like this comes up and is,, burning on the house and interrupting the backlog, I want it to be visible. Anyway, All right, let's cut to the next one, which is number two, the oversized product backlog. Now the quote here is the product backlog contains more items than the scrum team can deliver within three to six sprints. Interesting. Yeah. Three to six sprints is what, 12 weeks at best. Um, so 12 weeks is, that's a quarter, man. I was just gonna say, it's a quarter. You've got details in your backlog. that are beyond a quarter, that backlog is too deep. Most definitely. Right. Beyond a quarter, it's like, it's like putting vegetables in the drawer in your fridge and then coming to those three months from now. Yeah. They're not gonna be fresh. Right. So throw 'em out. Don't have 'em there. I. if I were to write this item as a list and try to sell people on using it, I would, I'd just say six sprints and I'd be done, I'd be out at six. I'd be like, Hey, if you can't get it done in six sprints, like I don't really want it in the product backlog. But then, but then when he says oversized product back, look like I don't, I don't know if he's, um, contains more items than the scrum team can deliver within three to six sprints. So just pretend for a second, he. more items than this team can deliver within six sprints. Like there's a lot of, there's a lot of stuff that's up in the air. Just when you say that, meaning, are you talking about all like the potential things or are these all refined by the team or are these, you know, how high level are these goals or whatever? The tough part of even going through this category at all for me is, as a product manager, I will put some stuff in the backlog that'll just, I know is so large. It's basically an epic masquerading as a story. But I don't really care right now. Cause I know we're months from even looking at it in refinements months. Yeah. That, that's a, so one of the things that I like to, , encourage teams to do, , the product folks, , is that's okay. You don't have enough detail. It's, it's way out there. It's big. We'll get to it when we get to it. I'm fine with all that. Then what I do is I ask them to put in a space holder work item. Yeah. Nothing more than just a whole bunch of equal signs that go across the screen. Right. Just to act as a divider. Anything above that is what we talk about with the teams, which is less than a quarters worth of work. Uh, the shorter, the better. you should have two or three sprints worth of, of a backlog in there at least. But yeah. All those big chunks that you don't wanna lose sight of, fine. Keep 'em there. Yeah. But we're not gonna talk about 'em. That's the key. Right? Right. We're not gonna talk about 'em until we get near the time, until those things get refined, maybe multiple times and there's more detail and they shuffle up above the line at some point. Yeah. Right. But that point is gonna be less than in this example and in real life, I feel. Right. Less than three months. I mean, it's, it's six sprints is about the limit. Yeah. Anything beyond that. Things are liable to change. Priorities change, right? Yeah. So yeah, it doesn't mean you have to not put 'em in the backlog, is what I'm saying. If you are saying the product backlog, do you mean stories that the team could potentially pull in? Do you mean like epic level? You mean feature level? Epic level because like I'll write feature an epic level and leave those sitting out in the backlog months before I ever engage because that's, that's like the potential branches that my roadmap might go off on. That, that's what that is to me. And as we de de determine not to go on those branches, I'll clip those branches. and maybe move them later in the road. Or maybe I'll clip 'em and just throw 'em away. I like roadmap level. This item where he's talking about oversized product backlog, I would clip this in half to say I can't, I can't consider what he's talking about unless we talk about team level versus potential product roadmap. You know, leadership level cause different discussions. A absolutely. So when he says the product backlog, like you say, it's not clear. Is it work items, is it epics, is it large boulders, is it small rocks? We don't know. Right. Right. But that said, I'm okay to see that in a singular, two dimensional backlog. As long as there's a demarcation of what we are really working on versus. that future stuff and that future stuff. Maybe just a one-liner. Yeah. There's no detail there. Yeah. Yeah, yeah. And maybe it'll get thrown away when we get closer to it. Right. So why spend the energy on it now? Yeah. So I agree with the three to six print time box., but there's some ambiguity about what he means, you know, by product backlog. Yeah. For me and my own teams, three sprints is about the cutoff, like three I I, if my team is three sprints ahead in backlog, refinement. And the business isn't really changing priorities. And the feedback we're getting when we demo the product is not really changing prior., and we have spaces on our schedule to go further in product backlog refinement. My personal preference is just to start removing backlog refinements until we, we get back to that sweet spot of two to three sprints ahead. I'll delete the refinements cause I'll say, Hey, like, we're, we're moving through work a little slower or whatever. Or maybe we're moving through refinements a little faster, whatever it is. But I'll, I'll try to, I'll try to give the team back that time if they were more efficient in other sessions, because I, I think in the future, You'll spend longer in refinement on specific issues and then shorter in refinement on other issues. And over time it'll all balance out. But, the product person can kind of align that, oh, are we two sprints ahead? Three sprints ahead? Two sprints ahead. And they can keep just moving around that time to make sure you stay in that two three sprints window. I, yeah, certainly I concur with that. I also think a point you made about pruning the backlogs also, often what I see is people leave things in their backlog Yeah. And say, you know, we have this deep backlog. It's, aren't we supposed to have a uppercase deep backlog? Yeah. Yeah. It's like, no., like I said, all these, all these elements just sit there and fester and they rot. Yeah. So, , I am all for pruning the backlog constantly. If you're not weeding your garden, and then it's just gonna be unkept. All right, Outdated issues. The product backlog contains items that haven't been touched for several weeks or more. I think, I think you're already like, ready to go for this. Hey, I'm ready to go with this one. This is like the second half of the first one. If you've got too many items, then you could have updated items, but if you didn't, then you can circumvent this altogether. So, so I think, you know, it's like one part of it precipitates the other. If you're not careful. Title just simply says, I outdated issues the product. MacLab contains items that haven't been touched for several weeks or more. Yeah, I mean, even with the price of eggs today, you'll leave them in there for, you know, a quarter. Not a good idea, right? Just buy what you need, when you need. So yeah, prune, prune your backlog and keep it small. Keep it., you're good. I got stuff sitting in the backlog and it's been sitting in there. They're not moving for a quarter. Okay. That's, I think it's fair for someone to say, Brian, you should look at that and decide if you wanna keep it in or not. Most busy product owners would just say like, well, I haven't, I haven't looked at it and nobody's it and nobody's update. and also assuming that nobody's actually going in, no customer, if you give them the capability has gone in and added, Hey, I'm gonna start washing this item, or giving a thumbs up, thumbs down if you have that capability in Jira. Basically what I'm calling out is anybody like the, the Atlassian forums where they, you vote up or down on whether you want features implemented and then there's like features with 12,000 votes or whatever and, and Atlassian ignores them anyway. Yeah. They apparently don't care. I would look at assuming that I'm not working at Atlassian and, I would look at these every couple weeks and, I would have a recurring list out of a, out of where, whatever my ALM tool could be. Jira could be anything, but if it were Jira, I'd write a query that says, Hey, if, if this item has not been updated, in whatever, 12 weeks, whatever, whatever number I wanna pick. Right? Days, number of days, , put it on a report and send it over to me. Cause I might decide like, Hey listen, we haven't done anything with this time, time to make a decision. Yeah. Certainly, certainly concur with that. I think you could, you can see on the backlog items that are, there for more than 12 weeks, more than three, especially for teams that are part of a, , a SAFe ART. Right? Right. Because you have a PI that's three months already. Yeah. And then people say, well, we'll get to that in the next pi. So you've got items for three months out already in your backlog. you know, as a product person, you've gotta be smart and say, okay, we'll keep some, but at the same time, can we keep so many that, you know, they're just gonna age and they're not gonna age well. Sorry. I thought, I thought, I thought where you were leaning with, as a product person, I'm gonna be like, why, why are we doing safe? That's kind . I thought that's where you were going, but I should have gone there. item number four everything is detailed and estimated. All product backlog items are entirely detailed and estimated. Oh, geez. I know, I know how ridiculous this item is. So, I'll put you right up first. It is a crazy item. So everything is entirely detailed and estimated. This is, this is where the team gets into refinements religiously every sprint. Even though, even though the backlog is pretty well refined and estimated for the next two or three sprints, right? Because it's in the backlog, we have to have a meeting and we're gonna go through it all. if your teams are doing that, you are falling foul of this very issue right here. Everything is well. So absolutely things that are near term need to be right, but things that are longer term, medium to long term, they don't need to be as much, , if they should be on the backlog at all, if they're truly long term. I've definitely seen this several times., this is typically when. Product owner simply doesn't understand, , how the backlog is, is supposed to be, , updated. I will admit, , I don't think I've ever been in an environment like this, really. I think, I think I was at one place that, , had this attitude that, , in order to, if, if you're gonna have an item in the backlog, it ne everything needs to be estimated. And, , the things that you don't want to be estimated, you keep them out of the backlog. And what that attitude contributed to was any stakeholder who could contribute things to the backlog they had, their own individual lists of all the things they thought needed to be added to the backlog in spreadsheets and whatever. So things only ever got added to the backlog when all the alarms were going off and all the things were on fire and all the things, you know what I mean? Like things only got added to the backlog until the, like, until they could not wait any longer. They got to that point. So that's the opposite of, , a backlog being too deep. Right? Right. It was probably not deep enough. Well, that was, that was what happened when you had this, this category is everything that is in the backlog has not only has to be considered, but also has to be estimated and, you know what I mean? All, all that kind of stuff. This item is fairly ridiculous for any like, working product manager. I'm throwing my ideas down on paper somewhere. Paper happens to be the backlog and I'm just throwing them in there. And the fact that they're in there means, means that they need to be estimated is kind of silly because I'm, it is This is why I like to use tools like planning tools, um, you know, plan, aha, et cetera. Mm-hmm., uh, to hold ideas and we source them directly from customers. Mm-hmm., anybody could put any idea in, but that's not guaranteed to be implemented or look at it on its merit. but it doesn't go in the backlog immediately. Mm-hmm.. Right. But if you have that situation where the backlog contains a lot of ideas, at the very minimum, use a prefix of. I don't know, idea at the beginning of the title . And, and know that your teams isn't gonna worry about, your team's not gonna worry about that cuz it's just an idea at that point. Mm-hmm. Invest. All right. Here is the next, here is the next one. Number five, invest Question mark. Why is there a question mark there? Invest doesn't have a question mark. The Scrum team does not apply the invest principle to product backlog items. All right, hang on. Let's cut over here to Wikipedia for help within the invest principle. I is independent and negotiable. Valuable. Estimatable, estimatable, estimable, estimatable. Small, testable, INVEST. All right. The antipattern is not having every product backlog item fitting the invest criteria. I'm on the fence on this because here he's saying if you go back to the, um, the criticism or, or the point mm-hmm., the scrum team does not apply the investments for the pro backlog items. To me, that's too general because a pro backlog item has that notion of immediacy versus latency. Mm-hmm.. So if you've got stuff that's near the top of the backlog, you should be doing this. Right. You should, you should be applying the investment principle, making sure they're small enough, testable. Estimatable. Mm-hmm., et cetera. Mm-hmm., then you've got that stuff that's, you know, lowered down. You, you don't have to be doing that. Yeah. For those work items, right. Yet. Yeah. Right. Over time, you'll get to them if they're still around by that time. So I don't know what he's saying. Is this, he's, is he saying that, uh, the Scrum team does not apply them at all or to all of the backlog items? I'm not sure how to read this. Let's pretend that the Scrum team doesn't know anything about the Invest acronym. They never heard about it. they don't know what that means. They're just writing stories and acceptance criteria. in that scenario you're gonna see some evidence pretty quickly that this is not happening because stories will be too large, maybe too large. If fit in the sprint, the requirements might be too ambiguous they may be producing stuff that is truly not valuable for the customer.. Mm-hmm. the V and invest. Mm-hmm.. it's a great idea, but is it really Right? Do they get value out of it? Um, so you'll, you'll see evidence of this Nice. Pretty quickly. When I'm looking at the individual items inside of the Invest acronym, I think it's kind of interesting because I, I would figure. It, you can get all, everything in invest you can do and get easily without the V You can have independent, negotiable, estimatable, estimatable, estimatable, small and testable increments of work, and you can have all day long, but it's not connected to value for the customer. Then why do it or the other way around? I could, I could easily see the other way around because you have, you have any one of these items plus valuable and that's a whole different . Discussion. If I could stack rank this list, what would be number one in the invest. I was gonna say independent. That's way too many. I'm, I'm thinking Beyonce. That's, that's what's wrong with my brain right now.. if I could stack, rank, invest and it would be called Invest anymore.. I, I concur with you. That v trumps pretty much everything. You're right, that's out there. Right? Valuable. If you're doing that, then there's really nothing wrong. VINEST, VIN, you know, then you're talking about process. Right, right, right. Is it small enough? Can we fit it in a sprint? It's still valuable, sort doesn't fit in the sprint, fit in two. Yeah. You're delivering value. So, yeah, I agree. I think V trump's everything there. Yeah. Everything else that's un that's around there. These are all process related issues.. Oh boy. So like see our podcast on, uh, the what and the how. Mm-hmm.. Oh boy. Process. Process. It's important. It is. all right, so let's finish with invest and go on to missing acceptance criteria. There are product backlog items that need additional acceptance criteria without listing them all. I got some business analysis bones to pick with this item right Quick missing ac I view acceptance criteria as if you were to do a demo and users of that item were to come to the demo, your, the agenda of your demo would walk through acceptance criteria one, acceptance criteria two, AC three, whatever. That's the way that I have learned and do write my acceptance criteria. yeah. So look on the whole, I agree with you, but I'm reading between the lines here. He's saying without listing them, why wouldn't you list them? If you missed them, that's a different conversation. However, not all acceptance criteria are, demonstrable. Demonstrable, , in the review. Like, for example, NFRs. Okay? If something is scalable is, is how, is that something that you can show? Maybe you can do some markups. And do some artificial load testing and things like that. People don't do that in a review necessarily cuz the audience isn't really expecting that.. . But the contract they have with you is this thing will, uh, scale up to a, let's say a hundred thousand simultaneous users. Sure. For example. Sure, sure, sure. It's hard to demo that, but it is an acceptance criteria cuz they don't want it to choke once it's in the wild. So I think that's maybe what I read here between the lines is, you know, there are, there are acceptance criteria that are missing. Yeah. My, uh, my 2 cents worth here, I'm not that generous today. Maybe my 1 cents worth here is split those out. Right. Split those out into a separate. backlog item that says, this is a dependency now. So this, this scaling piece is separate. That has to be met before this other thing that you've developed, right. Can be, , deployed in production. I like it. Well, that's missing acceptance criteria. Let's move on to number seven. 100% in advance. I feel this is the previous item taken to the next level and then shot to the moon., uh, . The scrum team creates a product backlog covering the complete project or product up front.. I realize how crazy this sounds, I also, have been on programs and projects where the business says we need to know what 100% of everything that this project is gonna do. We need to know how long that's gonna take, because usually because they're trying to go up for budget or they're jockeying for money, or they're trying to write a pitch for the program or many, many other things. So while I, I also scoff at an an item written like this talking about like, oh, I need to know 100% of what's gonna happen in advance. There's also the concept of you having to, you as a product person, having to demo to investors or people that are looking for three years out for your company. and you have a need to fulfill with that type of audience. For people trying to build a program over time, you need a, you need something, you need something, you need a roadmap. You need something that says, these are the things that we are trying to do over time. Yeah. I, I think you do, you need to have a roadmap that, basically showcases what you're trying to do. Absolutely. Agreed. You know, when, when he is talking about a product backlog, however, right. Specifically, creating everything upfront in advance. A hundred percent. Pretty accurate There. A hundred percent, yes. Where I've seen that is in scenarios where people are, oh, I wanted to say generously transitioning from that old waterfall mentality, right? Yep. But in reality, they're not transitioning, they're still stuck there. so with their feet in the, you know, in the mud, what they're trying to do is, Get everything documented and then signed off in blood requirements. Signed, signed off, and those requirements are your product backlog. Yeah. That's where I've seen this. And of course it doesn't work because you could get your signature, right? Sure. You can then go about your merry way and then the minute something, uh, deviates from the original list, you could jump up and down and say, change request. Change request. The investors' going so? My business has changed. So that's where I've seen this typically, um, project managers creating, you know, Work playground structures for the whole product. Yeah. Day one. Yeah. So they spend three days Yeah. And come up with this thing that's gonna span a year and say, this is what we need. Yeah. Like they know authoratatively to lay upfront. Well that's, I mean, that, that right there is an interesting topic to talk about, which I don't know if it belongs inside of this podcast, so of course I'm gonna talk about it. Old school organizations usually will go to project managers to say, I don't know how many people I should be looking to hire for this program. You need to tell me basically, how, who, how many people should I hire? How many teams do I need? How many of this, how many of that? They'll go to a project manager for that kind of information. is there even an equivalent? Does that in any way intersect with this a hundred percent in advance kind of thing? I, I think it does tangentially. so again, going back to this discussions around the product backlog mm-hmm., so that project manager, I dare say, isn't equipped to create a product backlog. No. different p for starters. Yeah. But what they can do is they can say, high level, this is what we need here. Are they again? High level work breakdown packages? Yeah. That they create and they say, we, and this is where there's no science., they fall back on what in traditional project management is called analogous estimation, right? Yeah. They say, well, I've done this sort of thing before. It's not exactly the same, but it's pretty similar. Yeah. So we think it's gonna take about the same, roughly same amount of time, that's how they derive the staffing level needed. Um, unfortunately that is never accurate. Actually. Interestingly, it was never accurate. or even close, even in the waterfall model. Mm-hmm., the reason being every project is unique. So I, I think there's a little bit of intersection here, but only to the point where you are just a, you're, you're reflect are reflecting on a previous project and kind of estimating from there. Yeah. B, whatever you are estimating is very high level. It's not really a.. Uh, so if you are talking about really fleshing out the product capabilities and the attributes of the product Yeah. The functionality a hundred percent. Yeah. That's what I read here, right? and maybe I'm missing it. No, but if that's the case, then it's wrong. No, you're right. If you don't know what you don't know. Yeah. I, I, uh, I think it's kind of silly. I, I, I'm not sure if it's even possible to cover a hundred percent, like. Even if you're really, even if you're a really, really, really lucky ba, I, I just don't see it happening. No. Okay. So we're done with number seven and we'll move on to number eight. No more than a title. The product backlog contains items that comprise little more than a title. Oh, I , I understand. Sorry. I don't know why I read it. So creepily like, I, I don't know why I read it like that. this is actually a really, really normal thing to run into in product management, scrum Mastery team even being on a team, going to another team like you get to another team and they don't talk about how they're gonna implement anything. Everything's just like a title with no description at all. Maybe a couple comments. Maybe some links and that's it. And it's just a title, like no acceptance criteria, no nothing, just a title. If you, if you're working on a product backlog item that has only just a title and nothing much more than that, yeah. That is an anti, that's something you need to squash down. But if you've got just one liner is just a title way down in your backlog, I'm fine with it. Yeah, because you're not gonna get to it anyway. Yep. You may never get to it, so why invest the time in fleshing it out? This is a good one. No more than a title it's being brought up in this context as product backlog item level, which makes me think team story level. Yes. The team's just not spending time on refinements. The team's not really spending time planning. They're kind of just, they're kind of hoping they can, pick it up and figure it out and, they're not thinking they need to spend time talking about how to implement things. That's what, but the nice thing about this is this could apply at any level in the backlog. This could apply. I, I want to take this up one step above the team level to say all of your epics or whatever features or whatever they're called, they're all one line with like, no, no good business case, no good. Like, no, no set of ideas. No set of like, Hey, we tried this, or, Hey, these metrics or these whatever. So if you, if you punch up from your story to the higher level and you see absolutely nothing, yeah. You, you run, run. You're okay to be worried. you're cleared by the arguing Agile podcast to start asking questions about, ooh, what's going on here? Why is, why you are double certified in that case. Yeah. I'd also A level down from this, from the story level down to like the developer task level, whatever you, I dunno if you call that subtask in Jira and you call it something else in, in, in Azure, DevOps, I can't remember. Task. Yeah. Is it tasks? whatever level you're at. Like if, if those items of like the, the, the actual step by step like do this and then do this and do this, like the steps to implement, if those items are also just a title and the team hasn't actually like drawn up database diagrams and drawn up, how, how the Kafka, the topic is gonna look like. They haven't drawn up any of that. I would also equally be worried as much as I'm worried about there not really being a strategy and I'm doubly worried about there not really being any implementation details. So I'm worried about both of those. You make an excellent point about implementation details cuz all too often we've seen that., X doing X, Y, z refactoring this, doing this, but there's no detail underneath that. You know, I'm writing an api. Oh, where's the API spec? Where's the contract? You don't see that. So you absolutely agree with that. I do wanna go back to the, the point, though, no more than a title, cuz who is writing this stuff in the product backlog? Potentially you could feed a, you could feed into this from the customer base, their wishes, desires, et cetera. Yeah. And they will be no more than a title. I guarantee you. They, they don't have the know-how to write any more than that. They just say, well, you know, I want purple M and mss. That's it, that's the title. Sure. Now, now you've gotta figure that out. So two things there that could be a different. Sure. Altogether could be, or it could be the same backlog, right. Where it could do this number of different ways, a tag or whatever it is. Yeah. The way you identify, just these things are very high level boulders and they may never get broken down. So in that case, is it okay to have no more than a title? Yeah, I think so. Yeah. Because the team's never gonna touch it until it's really broken down and, size refined, et cetera. So yeah, I, this one's a bit more a nebulous one for me. Yeah. I, I definitely agree with the upstream stuff, like if it's, if it's large, large rocks, I mean, it, it could continue to live upstream. Upstream, upstream, , upstream. I like that one. That's Freudian. It could continue to live Upstream f forever. Anyway, that's step eight. No more than the title. Let's move on a step nine. Storage for ideas. The product owner uses the product backlog as repository of ideas and requirements. I think we've hit the first one in the whole list that I actually pretty much flat out disagree with. It'd be nice if I had a visual representation of this, but I don't. So here we go. All right, for all y'all, for all y'all listening, for all y'all on video, I'm doing this for the people that are listening That's my excuse. When you write an epic in the backlog, that epic should be encompass a business case, okay? When you go to figure out, when you go to figure out whether or not you should do something to further that business case, there should be ideas. And out of those ideas, you should have ways to test, prove, disprove those ideas. I believe all of those tests should be attached in some way, shape, or form to the epic that the stories of the team picks up. Are also tied to, so that the team, if they care to go look, can go back and review the product manager's ideas that led them to the work they're being asked to do. This is ideal world type of solution. I, I do have to admit, but that's kind of the way I feel. That's, that's, that's the main reason I feel though, like, Hey, don't tell me I should store my ideas somewhere else that's not transparent to the team. I'd rather store my ideas in the same place the team does. Its work in the containers, in the same containers actually, that the team does its work. Yeah. So I certainly agree with you. I don't agree with this as being an anti-pain because the ideas, , could be put in the, um, backlog as a, as a repository. There's. a benefit to doing that, even if those ideas will never come to light. The benefit is if the team can see those ideas, it may influence the direction, the technical direction they're taking now in order to make those things happen. that doesn't mean that that idea is gonna be fulfilled necessarily, but a conversation could happen. So architectural direction may pivot based on what's coming downstream. So that's a big benefit there. So the other thing I wanna say about this is, why is this an anti-pain? Put ideas in your backlog, use a prefix of idea. I, you know, I, for a large program, you could use tools, other tools to, to solicit ideas directly from customers. I like to use aha, I use Aha to, to basically extend it out as a portal to the customers where they can put their ideas. They come in and they sit there until a product manager reviews them and decides what's worth pursuing. But that doesn't make it in the backlog in that scenario necessarily. However, if you don't have that, you just have a system, an LM tool that just has a backlog. There's nothing wrong with keeping them there. Sure. If you've got 50 ideas in your backlog, That doesn't mean your backlog is too deep. That's not your working backlog. That is just a repo Yeah. At that point. Yeah. Yeah. Which is why I'm fond of putting that demarcation line in which most ALM tools don't let you. So I create a work item that just has a bunch of dashes or equal sign.. Uh, and manually move that around. This item is kind of sad that it is lagging so much behind the way that people work. The issue here is where is the product manager or really anybody who did discovery work in a sprint? Where are they gonna put their learnings? Into the system, where are they gonna put their notes and if you're saying them, putting them in the product backlog is an antipattern. Is that really the best message that you're putting out? Because you're, you're saying we want you to keep your ideas and learnings in another system that's not connected to the system that we may or may not be implementing things. Yeah. I, I don't, I don't think this is a great one. I don't think this is a great one at all. Agreed. I have a lot more ideas than this one. You could be opening submissions. You could be ranking submissions. You could be doing a lot in the system. I, I understand. specific ALM tools are not great at handling this. In that regard, I'm on board with this. But that doesn't mean you shouldn't do it Yeah. I agreed. Number 10, part-time po the product owner is not working daily on the product backlog. So if they're not working daily on the product backlog, what are they doing daily? That's my question. Working their other job. Right. Cuz they have five teams. Right. Okay. Look, yeah, I, I'll relent and say if they're not working on the backlog, you're right. When they're talking to customers because that's why they're not working on the backlog. Okay, great. I'm fine with that. Yeah. But I know they're not talking to customers 24 7 or seven hours a day. Eight hours a day. I mean, I know that, I mean, look, I've been with. Product owners who've been three different teams, that three different teams, three different customer bases, three different pools of stakeholders, the only person seriously impacted is the product person, cuz they have actual different teams. So I got on one hand. Yeah, I mean, I, I, I understand what you're saying, but on the other hand, like a lot of companies are like this, where they, they divide they're product person and say, oh, you can do 25% with this team. You, you're just kind of keeping them on track and then moving on to the team. Right? Right. That's, that's all you're doing. That's like saying, look, you go to a, a large supermarket and have one person in charge of the bakery and also in charge of the, , the, the seafood section. And come on. It doesn't work. We know it doesn't work. It's a fallacy . so part-time POs Yeah. Don't do it. There we go. I like that. We didn't really put, put any . There wasn't any like, gray area with that one. It was like, yeah, don't, don't do this one. This one's silly. Don't do this one.. All right. Copy/Paste PO The product owner creates product backlog items by breaking down requirement documents from stakeholders into smaller chunks. I feel personally attacked by this one. I think this is a great article, first of all. Okay. Yeah. But second of all, whoever wrote it, like they had a big problem and it was like their specific problem. I guess you could apply a feature factory to this one as well. You could, could, yeah. A product owner who is basically just a feature factory product owner. They do whatever they're told in the order in which they're told and they really don't push back and they really don't know anything deeper. Whatever. That, that could be this one as well. I was gonna push back on this one to be like, you, you're really being weird. I think this warrant's being pushed back. So part of me wants to say, Hey, you know, if the customer's got some decent stuff there, I'm gonna pick and choose from there. Copy paste. I'm fine with that. Sure. I'm not gonna take everything they've got or just do the copy paste. I'm gonna do a little bit more than that, actually, quite a bit more than that . But I wanna maximize the matter of work not done right. Why would I redraw stuff that they've got or rewrite stuff that they've got in its entirety. I mean, I may want to add clarity, et cetera. That's fine. Yeah. So this is kind of weird, a little bit. Uh, copy paste, po. It, it is weird, like I said, I think it's a unique situation to whoever wrote the article about, uh, I have a PO who's just a project manager in disguise and they just cut parts of the PRD out and paste into stories in Jira well, one of the things that leads to this though is having part-time pos, cause the poor person doesn't have enough time, so all they're doing is copy, pacing, calling it done. That is true. Yep. Number 12, the dominant po I'm putting the, the, in the front of it because it's fun., the dominant po the product owner creates product backlog items by providing not just the why, but also the how and the what. Oh boy. So, Om, all the times we talk about, product people, , that come from the business that have no technical skill., this is the reverse of that is the product. People who do have technical skill and now are telling you not only what to build, but how to build it. That's, uh, the, the worst of both world. The worst, the absolute worst of the worst of both worlds will be product owners who have a technical background. Of some years ago, and they'll say, yeah, this is easy. You see this is all right. cool little program. And it's one. It's a one. Yeah, yeah, yeah. We could do this with kicks and DB2. This is extremely dangerous. So first of all, going back to the statement though, the product owner creates product backlog items by providing not just the why, but also the how and the what. So I wanna pick that apart a bit. Right. I'm okay with the product owner providing the why plus the what? I'm not okay with the product and providing the how whatsoever. Because if they just say the why, we wanna increase market share by mm-hmm., you know, 30% that that's. Okay. That is the, that is the what I suppose. What, what do we wanna do, but why? Right. Uh, so what and the why. I'm okay with, I'm not okay with the, the how. All right, before we, before we get into this one, let me, let me look at the last one. There's only 13 in here. Okay. Yeah. So thir number 13 is the, I know-it-all po. The product owner does not involve stakeholders, teammates, or subject matter experts in the refinement process. I want to do this one and then go back to the dominant po because I, I feel the know-it-all is, an easier, faster conversation than the previous one. It is, it certainly is. These are the OPOs, O P P O I call those one person's poor opinion. This person is the know-all. They think they know, but they don't know necessarily. Right. Typically they don't know. Right. They think they know. So this person comes in and says, here is what we need. I'm gonna tell you what we need to do. Exactly. Right. Right. Um, they probably, I'm willing to bet they've probably never talked to the customer because they know everything. What? I don't need to talk to the customers. I know what they want. So with, with people like that is, I guess the articles saying that that's an anti-pain, they don't involve stakeholders, et cetera. Yes. Yeah. Fully agree on this one. Right. It is an antipattern. Yeah. And I think it's difficult for the teams because typically these people tend to be what the previous, , item said, you know, the dominant person. Right, right. They tend to be dominant where the teams don't feel comfortable pushing back. Because their opinions are so weighty. They come across as def facto the Correct Yeah. Things to do. Like, well, I'll, I mean, I mean there is that, but also there, there is the, used car, oh yeah, yeah. There's a used car example of like, if I roll into the used car lot and I just start like, Hey, how much is that $4,000 car worth? And like I, I've effectively set the value, I've effectively se anchored the value in my first, like that's the way, like when I read this, that's the PO coming in the room to say like, we're just adding a field to a form on a, an HTML website, whatever. That's a one that's that's a one. Right, right. Right. That's a one that should take a, that should take not even half a day. Right. Couple hours, two hours. Right. Right, right. Yeah. Like, like how much discussion can you invite when you have one person already who's kicking off the conversation already anchoring the conversation So basically, whatever you are gonna come up with you know, you're gonna be automatically challenging the person. So there's a whole bunch of like psychological tricks happening right now of like, do I really want to, like, do I need this?

30 or 9:45 AM in the morning on Monday morning? Do I really need to get straight in a fight at 9 45 A? Om,, I'd rather just drink my coffee.. My, my, my second coffee, that's my decaf for the day because I already had my full strength coffee. Maybe this is my last meeting in the morning. Then I don't need to have any more meetings until the end of the day. Like, do I really need to fight? Do I really need to get in this fight right now? You, you really don't. I mean, you need to, I really need, I don't, you need to end this meeting early by saying, well, you seem to know what to, what to do and how to do it. Yeah. So you do it sounds like That's what I usually advise the team say. Sounds like a a three. It sounds like a three. You said it's a three. I think it's a three. Because you said it's a three. I'm not gonna fight about it. We'll get outta here and at the end of the sprint if it ended up being an eight and not a three. I, I don't know. Like, who pays for that? Hey, if you think you know what to do and how to do it, go ahead, full. Power to you.? We'll just assign that item to you, Ms. PO. Mr. PO. the problem with this is the person who's usually throwing out the numbers is almost never the person who becomes responsible when that number is not hit. Very true. That was 13. cut back one more time. It was the dominant po product owner creates product backlog items by providing not just the why, but also the how and the what. So I had a bone to pick with this one, which is, not just providing the why, but also the how and the what. Okay. So let's, let's pretend that I wrote this for a second, just for the purpose of dissecting it. Product owner creates product backlog items by providing not just the why and the what, but also the how.? I'm gonna, I'll reword it to say it like that, because. The business brings the why to the product owner. If there's no, why, there's no business strategy, and y'all should be asking other questions. If there's no business strategy at the place you're working at right now, that's my psa. Amen? Absolutely. So let's talk about the product owner bringing the how for a second. Cause this is the, this is the part where I want to get into. So the product owner, generally speaking, shouldn't be, shouldn't be telling the team how to implement things. I think we can both agree on that. Yes. I think where we can start dividing where we agree is in the case where you have a development team that is being asked to do things that they've never done before. Like, let's say for example, you have a development team that only ever worked on backend systems and now a new product manager comes in and a new, like, maybe they're trying to sell to a new client or whatever, and they're gonna ask the backend engineers to say, Hey, we need a new website on top of our applications that we have. And we've never done website development. So now you're asking a bunch of backend devs to do front end development. The dominant po like I have things that I want a website to look like. maybe I have examples or I have, you know, style sheets or maybe I have a corporate website and I'm like, Hey, this is a color scheme, this is a style sheet. This is the sizing and all that stuff I want you, whatever you do to be in line with the corporate website. So like, I'm laying down for some very specific stuff that someone might consider, oh, you're telling me how to do things. I don't know. I think that's still the what, right there. There's, they're basically specifying that you should abide by the branding, rather than how you should do it. Some teams could get confused with, with the what and the how. I'm sure it can happen, but to me it's pretty clear, right? If you're saying, yeah, you need to really be in line with the branding of these other websites, that's still the what. That is not the how, sometimes what happens is, , the product owner, a weak product owner, is basically, steamrolled by the likes of an architect. Sure. And the architect can now fully get into the how, right? Mm-hmm. in that case, it's not as much of a, a risk because they are technically capable, hopefully. What I have seen is anecdote I wanna share really quickly here. I did have a product person who, uh, really wasn't all that technical, but, could read tables, ERDs and things like that. So they came in one day and said, all we need is this field that needs to be added over here. And didn't really specify what it's gonna be used for, but why need this field at it? Yeah. And of course they do some ego stroking, right? Oh, you're a great developer, Brian. You can have this knocked down in an hour. True. So of course the developer does what they're asked. Right. And um, and lo and behold, what happened is they wanted to do some searches by that field that he put in. Well, long story short, the whole system ground to a halt cause there was not an index field. So there's danger in being just technical enough. Yeah. You want a doorknob? Just tell me you want a doorknob? Yeah. Don't tell me you want a high tech. door opening device. Yeah., table scans for life, like you're talking to the wrong guy., like, like what you're talking about kind of goes back to, item number one. Prioritization, but proxy. Yes. Like if you're, if you're product owner slash product manager, the, the, the person that we're kind of targeting with this podcast, if they are, abdicating their responsibility off to, uh, some kind of architect. Yeah, I don't know a good way to say it. Then, yeah. Some of that is prioritization by proxy. There's a bunch of stuff that we're not gonna get into on this particular podcast about, feature development versus infrastructure development versus platform development versus a bunch of like all the different things that, that will come into a product's backlog over time. Yeah. Like this, this is not really the podcast to, to delineate them and talk about how, how they balance and stuff like that. But if a product person is running your backlog and the team is contributing to your backlog refinement, like, I don't know, a lot of these problems that are here are pretty easily avoidable. You know, you're violating some of these 13 things. if your product isn't really satisfying the customer. You know that. So now you can go back and figure out which one or ones of these you're falling foul off, and then hopefully, you know, you can remediate those. The note here to add is if you see any of these things happening in your work center, we gave you a few, suggestions about getting around them For example, if you have a project manager or whatever, asking for 100% of everything in your backlog in advance, I mean, at least you now know that that is an antipattern because again, the backlog is supposed to be emergent based on feedback from whoever you're showing the items to as you're developing them. Indeed, in the just give you project managers a hundred percent of the next three sprints worth of a backlog.. That's right. That's it. That's right. Oh, wouldn't go past that. I really wouldn't. Well, listen, let let us know what you think about this topic and any other topics you'd like us to delve into., just comment below and smash and subscribe that like button.