Speaker 1: How do you handle changing or conflicting requirements from stakeholders? Well, the great thing is as a scrum master, that's not my problem. That's on the product owner, that's on the business representative for the team, whoever you may, whatever you may call them, really it's on them, not on us, but we are there to support them. How are we going to support them when there are conflicting requirements coming in from stakeholders or competing requirements? It's going to boil down to prioritization. That's really what's going to matter. The role of product owner is really difficult. It's going to be really quite hard in these circumstances, particularly quite hard in these circumstances because we're going to be dealing with people who are passionate, have an expectation of getting their way because what they need is important to them at least. And your product owner is going to sit in the firing line because they're going to have to say no to somebody. The role of a product owner is not to make everybody happy, it can't be. We can come up with an almost infinite number of ideas. We can continually come up with new things we could be doing and new ways we could do it and new features and all of that stuff. The product owner and the scrum team are mere mortals. We have a finite amount of people, of time, of ability, of money, and therefore we can't meet infinite demand. So we have to say no. And the key here is getting really clear on priorities. Whose is more important than whose? So our role as a scrum master is not to make this decision, but it is to support the product owner in making that decision, in helping them, giving them the tools so that they can do it and they can do it well, and that they can justify it to the stakeholders because somebody's going to end up upset at the end of this conversation. I'm doing yours and I'm not doing yours. People you said no to are probably not happy, however, they are professionals and they can understand that you are managing a budget, that you are managing a limited amount of people, of resources, and therefore you have to make tough calls. So we work with that product owner so that they can make that decision, they can make that call. And what we want to do is get really clear about how to prioritize. I'm a big believer in strategy. It's not surprising for a strategy consultant, but understanding the organization strategy and how we measure that strategy. How do we know we're going in the right direction? That's going to give us tangible measurements, things that we can see, dials that move, however they appear, and you're going to have a product strategy, what your product is there to do for your business, and that needs to have tangible, measurable things. Great, because if we've got those, we now know what's important. If we move these needles in the right direction, we are probably doing the right thing. I wish it was quite as simple as that. There is definitely nuance in that field, but to boil it down to the basics, you're going to end up with a handful of key drivers for your product. Brilliant. Every single item in your backlog, everything on your roadmap is there to drive those needles in the right direction. Because if they're not, why are they there? It's a genuine question that you have to ask. If you can't place it against these, what is the reason that you should be spending time and money and effort on it? So let's assume that everything is there to deliver on the product strategy. Great, but it's not all born equal. It doesn't matter if we have conflicting requirements. It matters which one is more important to the product, just because they want the button to be yellow and they want it to be blue. So, well, you are going to, it's probably a little bit too trivial, but you are going to work through and work out that yellow is more important than blue. Therefore, yellow gets done first. And if when blue comes up, it's still a relevant thing, we consider it or we delete it. So for each item, you're going to compare it against those drivers. And you're going to say for item A, it's good. It's got a high impact on customer revenue. It's a low impact on customer satisfaction and employee satisfaction is basically a zero. For item B, C, D, E, and you're going to do that for all of them very quickly. And when I say all, it's probably, if I'm honest, not all of them, but most of them, you're going to do it to get an idea and the others fit in quite quickly. Very similar to what we ask the team to do in terms of effort, we are asking the product owner, not in isolation very often, but the product owner and stakeholders to do in terms of value. This is more important than that. This is more important than that. What you'll end up with is a matrix. And what we can do then is just say, how do we sum those numbers together to give us a final value score? So very simple. Okay. It might be that we have revenue, customer satisfaction, employee satisfaction, and it's all about the revenue generation at the moment. So we're going to multiply whatever number we gave the revenue by five and then we'll add them all together. Obviously, things that drive revenue are going to end up with a really big number and they bubble to the top because it's the right thing because we're focused on revenue generation. Now, what we have as a team, what your product owner has in particular, is a way to explain the order in which we're going to tackle the work. So this is incredibly impactful about revenue generation. My yellow button is going to deliver more money than the blue button. So we're building the yellow one first. Does that mean you're not building the blue? That doesn't mean we're not building it. It means that we believe, that is a hypothesis, we believe that building the yellow button is going to get us more money. So the yellow one comes first. Doesn't make the conversation easier, I'll be honest, because what you've still got to deliver bad news to somebody who is very often quite senior in organization and passionate about delivering for their customers, for whoever it is that they're talking on behalf of. But hopefully, by taking them through the thinking, by making it transparent, by laying it out in front of them and saying, do you disagree with the numbers? Not do you disagree with the end result? Of course you disagree with the end result, you're not getting your thing. But I don't care about that. I care. Do you disagree with any of these numbers? Are these roughly weighted in the right way? If so, then this is the answer. It's an objective thing. We're moving away from opinion, the subjective nature that many companies work with. If we want to manage conflicting stakeholders, we very often have to move them to neutral ground, move them to, this is how we view it impacting the product drivers, the business drivers. And if you don't disagree with that, this is the answer. And I'm really sorry, and I know it's not the answer you want, but you're not getting your requirement. They're getting theirs. And if you can tell me that we've got something wrong, and I believe you, and I agree with you, then we change it, and the sums work themselves out, and the order changes. But today, with what we know, this is the answer. What I found is moving to that, they can argue, they can argue with Excel all day long. It doesn't care. It's a computer program. But that's all they're arguing with is if the inputs are correct, then we're going to then the output is just the output. It's just what the maths gives us. And actually, what I found is most people, when you put it in that simple black and white space can go, okay, I understand why you've made that decision. I don't agree with it. So you don't have to agree with it, but I understand it. And they can be more accepting because what they can see is you're working without bias. You're helping your product owner work without bias. Obviously, there's always going to be some, but at least we're showing our working. We're showing the rigor of thinking and the openness, which gives them some hope that in the future, their thing may bubble to the top. Not because it's theirs and you owe them one, but because it's the better idea. And that's really what we want to get with prioritization. It doesn't matter if your team is doing extreme programming or Scrum or Kanban or anything. Ultimately, prioritization is going to be about delivering the right thing for the business, for the customer in the right order. By working together with your stakeholder, by putting everything down on paper, making it clear, making it transparent so that we can have conversations about that and not our opinions, makes the conversation, while not a fun one to have, a much easier one to navigate. If you've got to this point in the video, I hope you've enjoyed it. If so, a like would be appreciated. If you want to hear more from me, more answers to questions that maybe you've got in the Agile world, please subscribe to the channel. And if you've got a question that you really want answered, drop it in the comments. I promise we'll get around to it. Thank you.