AA81 - What does a Scrum Master Do All Day (Part 2: the Product)

this podcast is to cover the, , second part in the series about how the scrum master serves the product owner, and,, the method we're gonna use for this is we're gonna walk through each, factual bullet point from the scrum guide. There are four bullet points in the scrum guide, and, , I'm gonna ask two questions. I'm gonna ask, for an example,. And then I'm gonna ask who does this bullet point or the pieces of the bullet point in the case where the bullet point divides into several other subsections?, who does it when there is no scrum master in the organization? Because there are some people on the internet who, angrily protest that a scrum master is not, a fulltime position is not needed. So, , if you're a scrum master and you have to deal with, these people, this is the podcast for you. And if you haven't seen our first podcast, go check it out. Or our third podcast, check that out too. Let's start with, , so the Scrum master serves the product owner in several ways, including, including the first item, , helping find techniques for effective product, gold definition and product backlog management. That's a, that's a mouthful. That is, There's quite a lot there., so helping find techniques for effective product, goal definition, I think the focus. More on this now with the latest scrum guide that encourages setting goals, especially for the sprint. Mm-hmm.. And so people are thinking more around goal orientation, right? What are we trying to do? techniques for effective product goal definition. That kind of assumes that the, the product side of the house isn't proficient at outlining goals. Right. I haven't found traditionally that to be necessarily a challenge, but I guess it varies from organizational organization. how does this scrum master serve the product owner in effective product goal definition? And how does this scrum master serve product owner in, product backlog management? Yep. That, that latter part, , backlog management is really about keeping hygiene around the backlog and making sure there's just enough, but not too much. Right? Because if you have a very deep backlog, some product owners will say, Look at my backlog. It's awesome. I have 200 items in there and it's like, okay, well it's like filling your fridge with 200, fresh vegetables and fruit, right? It's all good for you, except it becomes stale. You can't use it. All right. An effective scrum master would kind of advise that, right? Of the product owner. The first part is a little trickier for me because product goal definition should be driven from product. And the scrum master can simply be the, I guess the, how can I put somebody who just vets that and says, does it make sense as a goal? Is it too big? Is it too small? That kind of thing. Yeah. What are your thoughts on this? When I think of the product goal, I think of the product goal being typically something that is done, before we ever even start building. And something that potentially, , can be changed or adapted to some extent, but usually doesn't move all that much., at least as we're doing larger development. so speaking to the broad, the product goal ex exclusively I think it depends on when they're coming in because a product goal is something that we need to be aware of in regards to defining, but I don't see that that is something that. And then we need to work towards, but I don't see that that's something that needs to be constantly iterated on or, or needs to be adapted on a regular basis, unlike the sprint goal, which changes sometimes regularly, every sprint or very frequently mm-hmm.. So what I think from a scrum master perspective is if they happen to be there in the beginning, right, they definitely need to help whomever is involved with creating that product goal, which is going to be a, I'm assuming a large, a large group of stakeholders, not just product. We're gonna have a lot of people that are gonna be inputting in this and as scrum masters. Role in that is to help that group of stakeholders, probably many of which aren't going to necessarily understand what that product goal potentially should look like when we're thinking about this being a really a, a far longer term. Goal as opposed, opposed to a short term. So helping that group of stakeholders, which obviously would include product, product management, product owners. So I see them more of a, as a facilitator in that regard. In regards to the product backlog management I see them being able to be that, so using the term rubber ducking, so helping the product owner or product manager, really talk through that backlog or talk through the prioritization , and maybe sometimes just getting that other perspective. So here's what I'm thinking. Anything that you're aware of, and a lot of times the scrum masters. Are privy to other teams and are, are potentially reporting in, in other manners, and so maybe able to really give some additional input in regards to that backlog management and prioritization. I thought of something as you were talking. Part of goal definition. I think that depends on the context. I go back to that. If you're a scrum master on a team or a bunch of teams at a company like Boeing, we talking about that earlier. Right? To what extent can you make an impact techniques for product goal definition? I mean, product goals are way above you at that point. Oh yeah. So you don't really even influence that because there's so many other things that impinge on it. Regulatory safety, regulations, compliance security, all of those things. So you really don't have much of a poll. All you can do is look for clarity in the goals, make sure they're clear. Make sure they're measurable, right. Same thing with the product backlog management. You have to do the things you have to do, but. As you were saying, is the backlog in a good state, is it too deep? Is it, is it emergent enough or is it static? And, and again, it should be emergent, but in my example, it's not as emergent. Because they know the things we have to do. Those are red. You can't just say, well, we'll figure it out. Yeah. Doesn't work that way. Cause you're building an airplane. Lives are a stake. Yeah. So I think it's contextual, in certain cases. If you're just building software in a typical software product organization, then yeah. Perhaps you can have a bit more of a, an impact. Yeah. I like, I'm trying to go along with you. So we're talking about the scrum master. Yes. So I have to. Take a step back with my little product owner hat on for a second, because as a product owner for Boeing, for example, for the aircraft manufacturer, for example, I am the product owner for the avionics systems, or I am the product owner for the hydraulic systems of the aircraft product owner for metallurgy. I don't, I don't know what the different departments will be. It's got 50 of 'em. Yeah, Yeah. The airframe for example. Sure. I am concentrated with my team. On doing very important, very critical things for my components on the aircraft. And I'm not lobbying for component based teams. However, we're talking about the scrum master who reaches out in the organization with a, a one organization vision in their head. This person has to be bringing techniques to take the individual product people in their individual areas and be pulling them into some sort of forum or venue where they are talking to each other, to not get so far ahead of each other and be lining up to the goal that everyone aligns to. That everyone is continuing to contribute to that goal. that's where I'm going with that. So, yeah, that when you like, it's, it's you, you serve product. That's what this category is about. You serve product the best when yes, you are helping your individual team cuz you probably got hired on one individual team, but you are keeping the whole system in mind and keeping everyone in line on all like, this might require you to reach out to other Scrum masters on other teams that are serving other teams. And they might be way more myopic about what they're doing than you are. Right. Because of different experience levels and Sure. Aligning the organization stuff like, It. But when I look at this bullet point, and I listen to your examples, and I, and I think of like, give me an example of this. And if you're gonna use air aircraft manufacturing is a great example of this because it's so difficult. It is it's so difficult for people to immediately break into component teams of like, well, I'm gonna, my development teams over here, my QA teams over here, my business requirements, teams over here, and they're all separate and they all gotta be completely done. That's not what we're saying. People can be assured that everything that goes into to, to producing the metal that goes on this aircraft is the best it can be. And it lines up with what the engine people need, what the fuselage people need, what the frame people need. But if you have somebody who is continuing to push you, To take a systems approach to all the individual components. I feel that's what that's what this, this individual bullet point is talking about, helping find techniques to more effectively do that. I think my product hat, I think a product person is in this position. I think like, well, what is your chief product person or your group product person doing? If not aligning your product people to be like, Hey, let's all get on the same page. This is saying a scrum master is sharing some of that responsibility, I think both. Right? So yes, of course your product organization is doing that. They're not developing in silos or even conceptualizing the product in silos. But here to this bullet mm-hmm., a scrum master on any one of these teams would be looking at dependency management because your team is producing one little widget. That's gonna fit into the bigger whole and you can be finished, but nobody can consume that or you're behind because everyone's waiting on you. Yeah. So that synchronization needs to happen, but how they help product here is making sure that the right level of quality testing is happening on everything. Start with your own team. But , integrating in with the next team and then the next team at every level there's testing going on and it's the scrum master who makes sure that that is included as work items. don't take on too much development. Yeah. Whatever that may look like in your sprint, because you have to test, you have to integrate with your downstream. And test and then provide that to your upstream. Yeah. That happens throughout, whether you're run by fuselage or propulsion system or engine, Right. Throughout. Right, right, right. And then you have what they call crosscutting technologies, Avionics. Well, where does that fall? It falls across everything. So, What the scrum master would be doing is looking at what their team is doing. Let's say, let's take a specific example. Let's say that their team is working on the hydraulic system. And there is even that is broken down into multiple, but it's simplified. Mm-hmm., it's hydraulics. So what do they do , when their team has something finished as a finished product, Right. Do they deliver that savvy scrum? They would say, this is one piece of it, but for our piece to work, it needs the corresponding software. Right. Which is the avionics piece. Let's integrate that in. But don't do it after you've developed your hydraulics. Build it in from the beginning. So your backlog reflects that. So have it integrated in and when you test it and everything's working good, at that point you could say, We're ready to integrate this upstream. Yeah. But at the same time, you're also keeping your eye on what is coming next. Right. Because your downstream is ready to deliver. So it's on a flow and, And the scrum master is helping product. Yeah. By making sure they know what needs to be in the backlog. Hey, we don't have this in the backlog right now, or it's way lower, but it's coming up in the next sprint. Mm-hmm.. Right. So bring that to in visibility. I think something that we're assuming, but I just want to call out and that is assuming that there is even a product goal, right? So and if there is, right? And honestly like right? So assuming that there is a product goal, oh boy. And if there isn't, so what then are the techniques for creating a an effective product goal? Who do we need get involved in that conversation. I feel like you, you hit a, you hit a huge,, I don't know what to call it. A huge problem, a challenge. A Titanic size issue, which is what if you're the product per or what if you're the scrum master and you highlight that the product people have no strategy to hook into to create a product goal. Because leadership is not directing a strategy down to your product people. And, and therefore your product people have no goal to hook into, to bring to the teams. This is both an example of giving an example of a real world problem and also an example of who does this when there's no scrum master, right? Who, who in your organization highlights and challenges leadership? Cuz that's where the strategy should come from. Who challenges leadership in the organization without a scrum master? This, I want to ask this question specifically before we. Who challenges leadership specifically and says, You have no strategy. We need a strategy before the development teams continue. Like creating random software. I don't, I don't even know why you're creating software at that point. If you have no strategy, I guess I have two questions. How would you deal with that as a scrum master? A scrum, not a product person. Sure, a scrum master. How would you deal with that as a scrum master, and how would you deal with that in an organization where they don't have the scrum master? As a scrum master, if you are aware that there is no strategy right? How would you deal with that? You do have to pull out the, you have to pull the chain in that TPS or Toyota production system. You're right. Model. Right? Not TPS reports. Yeah. Not TPS reports. Yeah, just, just pull the chain and say, Listen, we're running, but we don't know which direction we're going in. Yeah. Much less where are we going? So how we know when we got there. Right. So let's, let's ask that question. And a scrum master has to do that. Yeah. So I'm gonna fast forward quickly here. Right. Well, well, well like welcome to working in a leadership position. Exactly. You are part of the leadership team. If your organization wants to claim you have a leadership team, not just a bunch of executives who are all running in different directions. If you really wanna claim you have a leadership team, this scrum master, welcome to being part of the leadership apparatus of the organization. Right. You, anybody on that leadership apparatus should be able to say, Hey, this strategy is not working. Or the strategy's not as clear as you think it is, any of the above. Yeah, absolutely. In, in an organization where there is no scrum master and who does this? You hope somebody would do it? If you, if you're looking at a, a deaf team, listen, it could be a developer who's savvy enough who's worked it's some experience, right? Who says, We keep building this stuff. Well, we don't know. And they, they would raise it to somebody, one hopes. Mm-hmm., There's no scrum master though. So who does that? Maybe the product person does it. Mm-hmm.. If there's no scrum master, a developer could do it. Architect, even a tester. Anyone can do it. But who does it? I haven't come across that before. Sales people do it. Sales salespeople will do it with their own interest at heart. Yes. That's the, that's the difference. This strategy is not good. Hey, look, I'm gonna get my commission in six weeks when I sell this. I mean, that's, that's he helping find techniques for effective product goal definition and product backlog management. Like if you are an organization that is a, a hardcore sales led organization the sales people bring your development team things to do, you implement the projects, bang out a piece of software, it's a one time thing, Stands alone doesn't integrate with anything else you do. It's just for that customer. You knock it out and you're. I mean, basically you don't really have a strategy. It was whatever your sales team brings you to bring money in, that's your strategy. You've built a liability, now you gotta support that one off. Right. For foreseeable future. That's not the salesman's problem. Or sales ladies' problem. I mean, they made their commission. Yeah. I can't, I mean, I, I kind of can blame them, but also like, I, I can't, organizationally speaking as a system, I can't really blame them. Right. Because that is what, that's what they encourage. So Yes. That's, that's what they reward. Right. We talked about that at another podcast it's the reward system Yeah. Of the organization. That's how they reward it. And I feel , there will be people listening to this saying like, Oh, that's my organization. Sales goes out and sells a feature that my software can't do. And you know, my, the, the product challenge to that is, well, are you giving them a roadmap and telling them, these are the upcoming things. These are the things you should sell. And are you bringing them into the conversation of building a roadmap together or are you cutting them out of that cuz you're afraid they're gonna disagree with you? And if that's the case, now we have an issue with product discovery. Mm-hmm. Now we have an issue with what we're talking about here, the bullet point number one effective product goal definition and product backlog management. If you're in a sales led organization and sales is basically leading your development team along the way and you're not in charge of where your product backlog is going, it's because you don't have an effective way to tell them these are things coming up for you to sell. What they're saying is, these are the things that I am able to sell from my conversation with the customers. Now you must build them so you like, you need to reverse. What's happening and you need to reverse that by talking to them and having more dialogue and having more understanding of what, I guess, I guess where I'm going with this is more empathy. That's where I'm gonna I'm gonna shortcut, I'm gonna hotwire this conversation. You need to have more empathy for where your customers are and where sales team is trying to take them. Build all that together. Specifically though, with the, I agree. First of all, but you know, with Scrum master, this scrum master role is a tough Yeah. Scrum master, right? So one thing they could do, one thing they might potentially consider is to shorten the value chain and talk to the sales people and say, Bring the customer in. Yeah, let's talk to them collectively. Not you go talk and sell whatever you want and tell us. Deliver, bring together, come together, bring together and say, what can we build? What are your needs? Listen to them. Right? And then build the appropriate solution. Oh boy. Rather than build something, hope it fits. The pertinent word and, and you said this earlier, Brian, Literally one word in that sentence. And that is techniques. Scrum Master's responsible not for creating a pro product backlog. No. And not for managing a product backlog. But for understanding what those are and for helping the product owner. To with techniques for making those effective.. Yeah. And what you've described, and both of you have mentioned multiple ways and techniques of actually doing that. Yeah. So being closer to sales, bringing in, bringing the customers in, making sure sales are part of the sprint review. Yes. So that, and given them the opportunity, let them, Yeah. Sit out a few times mm-hmm., and then go, You know what, Hey, we had, we actually demonstrated the, demonstrated this, we had a customer using it in our in our review last sprint or two sprints ago. It's an event that you've been invited to So those are techniques that a scrum master could potentially bring to the product owner to advocate for themselves. The scrum paster doesn't need to even be the one doing these things. Right. They're helping the product owner or the product person at this point. Mm-hmm.. So being aware, advocating and helping them to understand how they may make tangible some of these actual techniques. And you guys mentioned several of them. Yeah. But yeah, so it's that techniques and the communication and kind of the back and forth between the product on the scrum master. Yeah. Sometimes you can't just read about these. I have an anecdote to share about this. You know, some time ago when I was a young Scrum Master, one of the things that came out was in a sales led organization, I might add a global one. They built great products. Unfortunately customers didn't like them. And there was a gap there. So we knew there was a customer or user forum, whatever they call it, user conference, that's what they called it. Right, Right. Every year there, there'd be a user conference there in a different part of the world. And so like, okay, this is great because we have the users getting together and what the company was doing is they would be hosting it in a hotel somewhere. Users come in they get treated, all of that stuff. Right. Nice food. And there was maybe an hour of where, okay, what are your pain points? Right. And who was in that discussion was critical from our company. At the time it was project managers. It was customer service people that dealt with customers day in, day out. But nobody on the leadership level Yeah. Was in that hour long meeting. Yeah. Two days, one hour, nobody was there. And then the rest of the time it was between entertaining. Right. The rest of the time was. Well, it, it's a showcase, right? So here's Product X, here's what we're planning for you. Right? This is coming out next quarter. This is coming out six months. So I'm like, okay, this is a wasted opportunity. Right? So what we did is we turned that on its head and we said, instead of that hour, we're gonna let customers talk to one another and, and we will pull out, We won't be in that conference room. Yeah. We'll completely pull out as a company. So the company's not even there. Right. And the customers are there, they talk to each other, but they are given a goal. Their goal is at the end of that three, four hour session that they have, at the second half of the first day, they come out with a top 10 of issues that they're facing that they want us as a company to address. Mm-hmm.. And the next. They send that to us, right? So the next day we of course work in the evenings to discuss this as a company. Next day we come in and share our plans to address those or to not address those, right? Mm-hmm.. So who does that though? Not the engineers, not the project managers. Now we want leadership to come in and say, Here are the 10 things you customers told us. And they're on a big screen and with a laser pointer. We went through each one and said, Explain to us why, Why is this number one? Yeah. We're not gonna take it at face value just because somebody said, So why? Why is this one? Why is this two? Why is this three? And at the end of that, with that understanding a commitment, a verbal commitment was made, we will address number one and two in the next quarter. We can't tell you when. We'll get to three. We'll talk about that. Yeah. Well, let's stay in touch. Right. So there was no over promising. We're not gonna fix everything, right. We're gonna fix the top two pain points in the next quarter. Users well, so much better because they're gonna get their biggest issues solved in three months. Yeah. That is a huge change for where we were a year ago. Right. And as a scrum master, feel pretty proud of having just facilitated this whole thing. Mm-hmm., I wasn't involved, I wasn't even committed, to be honest. Right. The only thing that was the hardest part for me out all this, is to convince the company to pull out. They're like, But this is our, No, it's not our user conference. Think of the words. User conference. Where to say our name in there. It doesn't pull out. Leave them be, That was the hardest part with leadership. Like, you gonna leave them alone? Oh, they'll come up with all kinds of things. Exactly. We want them to imagine they did that with their teams. Whoa. With the, Oh wow. I mean, it's not the concept, the little sidebar, but anyway. Yeah. So Scrum to scan, do a lot. Just think outside the box. Who does. Finding techniques for product goal definition. Who does finding techniques for product backlog management? Who does that when there's no scrum master? Aside from, obviously aside from the product manager, like it's all in the product managers to be like, Hey, go figure out new ways to do your job or new ways to be affected throughout the organization. Who does it in real life? Very few people separate. So I would separate that into two. I would say that product backlog management, the most sensible if the if the scrum master is not available is obviously the, is product manager owner. And if they're not available, I think given your, what you were saying there is, is the dev team. I mean, they're the closest to and should hopefully have had communication and, and have some understanding of, of what's coming up in the backlog if we're having some refinements and things like that. Think of it from the perspective of like we've just gone through an agile transformation and we don't have Scrum masters who participates in helping make sure that we've effectively communicated product goals.. So goals was something separate I from a leadership, they are separate. Yeah. Yeah. So, so yes, I, I kind of took the back backlog separate, and, and I thought that was the easier one. But from a goal definition perspective that to your point earlier, really should filter down from leadership and be based on the strategy. If we're going through an agile transformation, the assumption is that we have people invested in leadership that want to make this happen. But my point is, yeah, you can see, I wanna jump in. In an ideal world the there's a lot of stakeholders, but that product goal should be driven from the. Vision or goal of the organization. Yeah. And a lot of stakeholders could be involved in that, but it should be driven ultimately from leadership as the organization that's done agile transformation and decided not to hire the people that can make it happen. I agree with all y'all and blink twice if you're in pain and you've been traumatized by , not having a strategy ah, like I agree with you. That's what should happen. And like I think everyone probably has been in an organization where things worked. Maybe not everyone, but like I, and I know for a fact that Om has been in an organization where things were working and then they changed leadership to somebody who really didn't get it. And now, You feel like you're back to square one, where there's no vision coming down from your leadership. So you're in, you're in the product position of saying, my product goal should be extrapolated down from the organizational level and in some way, shape, or form from the vision. And now now it's, it's not for whatever reason. And all of this is super easy to say, Well, well, I got my little silo. This is a product problem, right? Somebody else's job, leadership, job, product, owner's job. Okay. But we're not talking about any of those people today. We're talking about the scrum master today. So the scrum master has to have techniques. To coach up in the organization, which we might talk about this on a separate podcast, which may or may not come after this podcast. Sorry. I will maybe, I don't know. Where unless it doesn't, where they are empowered to climb in the organization at whatever level they need to climb to, all the way to the top, whatever, doesn't matter to say we have an issue with, we are not getting the vision that we need. I'm only speaking from my experience a lot of times.. The issue here that I've observed is the, the person in the role of the scrum master is I don't know if afraid is a good way to say it, but they, they, they are, they're not confident that it is their job to climb all the way up in the organization as far as I can go to get their problem resolved. I should take this back to the experience, I was a product person in the organization, but I also was charged with the Agile implementation. So it was like a pseudo agile coach. But I was a product. Manager in that organization. They did have a scr, they brought on a scrum master after I started to do that job full time, cuz it was, it was a full-time job. And in that organization I can't even remember why I was telling the story. Oh, oh, because in that organization I felt empowered to coach all the way up to the top, to the CEO level. Okay. But I could, I could clearly see other scrum masters. Saying, Oh, well these these people don't want to talk to me. Or they don't wanna listen to what I'm saying. They, they where people feel disempowered, where, where people don't feel like what they would say or what they would recommend is taken into consideration or even heard take, heard taken seriously. There's a lot of different things and, what I'm trying to wrap this bullet point up about how finding techniques for effective product goal definition. If you cannot extrapolate a strategy, you need to climb in the organization potentially to the very top to say, Hey, we're having difficulty figuring out what our strategy. That's, that's kind of where I'm going with this. And this might not be useful to people listening to the podcast cuz they might say, Look, well I'm in, I'm at this giant multinational corporation. I'm not gonna go ask the ceo. Well you don't have to go all the way to the CEO in that kind of an organization. Right. You can go as high as you can. So I would say yeah, definitely. One of the techniques since that's the bullet point we're we're talking about is, first of all, don't be afraid to coach up. Right. Get, get out there and go up. But if you're saying, Oh, I can't get to my vp because this calendar's full for the next month, I go stake out outside their office Gorilla tactics. I wanna say for people who are scared of trying to coach to that level, this is a product goal, this is strategy. This is a, this is something you should expect to be coming down at, at every level in the leadership. They should be repeating the strategy every level. If we go back to the John Kotter book Sure. Everybody should be repeating the strategy. So it shouldn't be a guess. It should be like, Oh my goodness, I've heard this so many times. This is the last thing I need to hear more about the scrum master needs to be really empowered and not intimidated, Right? To be able to be comfortable in that coaching up. So they need to be also given the coaching and encouragement and even the opportunity and potential kind of help maybe from a fellow or more seasoned scrum master or an agile coach so to, to get their feet wet in, in doing that. But I think all of this re is, is really wonderful sounding and in an ideal world, but it speaks to the culture of the organization, right? So if we have a scrum master that is empowered to speak up to leadership, then we probably have empowered teams as well. We have a, a, a good. Culture, but I think that that's not necessarily the case in a lot of, in a lot of places. And Scrum masters are squashed along with a lot of other people, all right. So second bullet out of four. Okay. Second bullet. Helping the Scrum team understand the need for clear and concise product backlog items. I feel this this item encapsulates a good deal of the BA skillset, like the, the idea of, and, and, and this is one that I deal with a fair bit of time as well Sometimes I'll split items for developers and say, Hey we need to do feature A, but like, this tiny subset of feature A is not important. We'll do that as a separate item and they'll say, Well, it's really easy to do together. Why don't we just keep it all together? And like, because vertical slicing, because we need to Right. Take, take a little bit of everything. I'm like, Well since we're in that piece of the code, let's, So sometimes it's negotiating with the business, but in my experience, a lot of times, especially with your, if you are with teams don't have a lot of experience with writing stories and breaking down, requests from users. This could be going back and forth with the team too. Clear and concise. Clear and concise also means, To me in the product position you don't start working on things that have blockers that are not ready for you to work on, and also you don't work on things that have not been vetted through some kind of discovery process, which is a sort of a, it is like a pseudo involved in this. So I like, I could, I could, we can take that one offline for a second. Just say let them figure it out during a sprint maybe. But Yeah, I agree with that. I think, I think you hit that one night. I think the other thing that a scrum team, so scrum team needs to understand clear and concise back on online. Where the scrum master comes in is if you don't have a BA specifically Yeah. Is to encourage the team to not start work on something that's vague or something that has a dependency. Yeah. Flip side of that, encourage the product owner to say you prioritize this high, however, We cannot work on it because Yeah. There's missing information. Yeah. There's a dependency on external teams or internal, whatever it is. Right. Make that visible ahead of time. Yeah. Yeah. And there are techniques, I know we're talking about techniques in this bullet, but there are techniques they can deploy here. You know, like making sure you use things like definition of ready and so forth. Sure, sure. Make sure that things are known enough. Well, I like, I like sometimes I like the shortcut definition already, cuz definition already could be contentious for some people. Cause they're like, Oh, you just scope creeping or whatever. That's probably why it hasn't made his way of the scrum guide definition of ready but, I like to think about this one is like, if you can't get unanimous approval from your team to say this item is ready for us to work on. I've seen some teams who go as far to put a status in their ALM tool of. Refined. This is something to indicate that the team has agreed that this item is refined and ready to be pulled into any sprint, that it basically indicates that discovery work is at an end. That team knows how they are going to implement this and they are ready. Or maybe they don't know, but they, the team is ready to talk about implementing this basically. Yeah. Yeah. A state or a tag or maybe a confidence vote, right? Yeah. Right. Anything for and above confidence vote. Yeah. Right. Yeah. In my experience of what, one of the ways that teams have, have done this, and, and this was the suggestion of that scrum master, was we used story points on this particular team. And once, once it was ready, And not until it was ready would we point a story. Yeah. So if it had points, that means it was ready. So that's what we used. Yeah. Right. Yeah. I could see that. Oh, that's what we used. I could see that, but it would be, it would be also good only because I'm in the middle of doing this right now where I work. It would be also good to reflect that somehow in the status of the item. I'm trying not to get into a waterfall here, but, it would be good to align at a feature level to say, we can't begin implementing this functionality that we know is gonna take a while to implement or whatever, until certain questions are answered. I would like, I, the product person, I know we're talking about Scrum master, I, the product person would like to have some kind of indicator to see on a co board at a high level, at a leadership level or at a product level. I'll say at a product level, we're producing a mobile app functionality. A we know every customer wants. Every customer needs. We've got these surveys, this testing, whatever we did that proves we wanna do this functionality. B. We've put some surveys out there. We've got some details that we don't have enough yet. We've got maybe like 20% of people responding to it. That's not enough for us to spend money on this functionality. C some executives said they really want we're bringing it into our discovery process to see if it's actually worth it. If people are using it. If we're validating, we're validating. We actually need to do that. So I would like to see on a I think of a kanban board right on, on some type of board somewhere. At a high level, this thing's been vetted and we approved. This thing's been vetted and we still need some more experiments, some more evidence. Evidence and this thing, we vetted it and it like it failed our vetting process. We don't see any reason we should implement that. There's no dollars there, there's no customer engagement. It's a good idea, but there's no tangible benefit. I wanna see that before I invest dollars from the development team that so like I, I know I, I went way off the . I went way off the rails to to say the, the need for a clear and concise product backlog item. The next bullet point is helping establish empirical product planning for a complex environment. Everything I just described if you, the scrum master can take everything that I, the product manager am doing, are doing, am doing, am doing whatever., if you can take everything that I'm doing there, I made it a contraction so I can skate outta that one. If you can take everything I'm doing and put it on a board that shows A to B to C A, I need to try something B, I'm trying to do something C, it worked or it didn't work. If you, scrum manager can figure out a way to visualize my work and make it transparent to leadership. My myself, quite honestly, in the other product managers and the team. you've helped me considerably because I know most product people in, again, only my experience, I'm only speaking from my experience. They do this work I'm talking about, yeah, hey, I need to do some AB testing. Hey, I need to survey some users. Hey, I need to figure out if people if, if there's an appetite for this functionality, but they don't necessarily show it to everyone and they don't necessarily bring it up at reviews. Every backlog, refinement or whatever. They, they're not necessarily showing that work. in fact, I would say they're probably trying to hide that, hide the work that fails through this process from the team. So the team's not distracted on this stuff. They get back to the development stuff, which I like. I'm not saying that's a good thing or a bad thing. I'm not, I'm not making a statement about that. I'm just saying if I had a scrum master who could show this stuff to, to show the team, Hey, here's the product vision., here's a direction we want to go. Here's what your product manager is trying to do, and here's what make, here's what makes it through the funnel. Now here's what you need to do. I, I feel, I feel that would be like that, that would make everyone feel a lot better about where they're at. What you're describing sounds pretty close, if not exactly the same as a lean business case. You know where these things are. What's the market need, right? What, what are potentially our markets? What kind of gain benefit will we get from this? Is it greater adoption, bigger market share higher revenues, whatever it is, right? All of that work should be done, but if it's not being done, a scrum master can help by providing that framework. They may not be able to fill out the details, but they can provide the framework to those that matter and. These are the things we need. So that's where they can really help. Yeah. And if you're a product person, somebody came to you and said, Here's a structured way to do this, an easy way to do this. Right. Great. It can be simple as well, it can be just a spreadsheet that they've shared, which has those relevant details on, You can download these things too from various, from various websites. But yeah, that, that's the sort of thing that I think where a scrum master can add value. I agree. I think that, so where they aren't necessarily the the most appropriate person in my mind to do this. Right. So doing market analysis but being aware and having some experience. How to do this and how to potentially display this to your point so that it makes sense across the board. So from product to leadership and and development team, so on and so forth, and creates ultimately that transparency. Right? So Crum, so they're the translator or the Scrum whisperer, right? The translator of Scrum. So finding tools and opportunities and ways and experimenting in different ways to find opportunities to create that transparency, I think is, is, is per, is perfectly aligned with what a scrum a master should be doing. In regards to just the, the clear and concise language, those, those three words, clear and concise. Yeah, I wanna go back to that too. Yeah. That, so. That can, it's very, it's very ambiguous and can be used in my experience, . So remember, I am coming from not a development background, so when it comes to writing stories, I am absolutely writing them from a user problem perspective. Sure. Yeah, yeah. Here's my problem. I'm not going to, or I'm trying really hard not to put in any resolution. Obviously, I don't have the ability to write in particular code or say which database to go to or whatever. But even so far as to say, I'd like to have a modal, or I'd like to, I, I, I need to be aware of those things and say, Nope, I'm not gonna ask for particular things as whatever user I need to solve this problem, mm-hmm., but clear and concise can sometimes be translated to really detailed, explicit instructional. Stories or whatever it is that you happen to be using that wouldn't be concise then. Mm-hmm., that wouldn't be concise. Right. If it's explicit, detailed, that's the opposite. I mean that no concise, is that right? Concise is succinct. Short, right To the point. As a user, I need this. Not, and, and you could go little. Well, I mean, I, I think you could, What I'm thinking is almost bullying point bullet pointing that out. So each of one of these are clear. Each one of these are clear and concise. I think you're saying the same thing. Yeah. Yeah, yeah, yeah. So I mean, I've seen this really be, become almost this anti pattern where people, developers who are usually incentivized to be fed information and to not, and, and not in an organization that is really embracing and, and, and empowering teams to be innovative. No, I I'm, so, I'm with you on this one because I, I went through this recently. Because my team was doing a bunch of UI changes. and , I worked on mobile apps for a good part of my career, so I have a real strong opinion on user interface because, again, working on mobile apps, you get beat up by users in the App Stores. Oh, yeah, yeah, yeah. If your UI sucks, I mean, you'll find out real quick And, and sometimes, like sometimes I, I say sometimes to not get in fights on the internet with random people. But reality is sometimes sometimes it says, sometimes again, sometimes a developer will tell you like, Oh, we just need a dropdown for this, or whatever, and I'm like, Mm, if you're adding a dropdown or like a radio button or something like that, I was like, If you're adding that, it's gonna look different on Android and iOS. Have you really thought about the user's flow?, they have to press a dropdown button. Right. And that sends them to basically another screen to choose either of the things like, have you really thought about this? Yeah. Okay. And then, obviously like depending on the organization, you might lose those fights, right? And then get beat up in the app store for every fight that you lost. You knew it wasn't something good to compromise on in the first place. So like clear and concise. Why bring this up is for me, there's a part of me as a product person, Again, we're talking about scrum mass, is I'm weighing as a product person. Sure. There's a part of me as a product person coming from my background working on development teams where I can take a UI and I can mock it up how I think the UI should flow to the user. Mm-hmm. and I can give that to the development team. Okay. The minute I do. And I do that for every UI screen. Like, am I now leading the development team? Am I taking away from the development team's discussion of the best way? Mm-hmm.. Yeah. I will tell you my personal preference is to give them nothing, just to write the story to say the user should do X , which should lead the user to doing Y, which should lead the user to doing Z or or Z if we're in the uk. Yeah. You're saying what not how you're Right. Right. Yeah. Right, right. I, I agree with that. I think there's also value in. giving that to the team and then giving them enough rope to come back with and say, Well, here's a quick Figma mockup or DX mockup, right? Yeah. How does this, how does this look ? And that's where, if I was wearing your hat as a product person, I would say, Okay, but let's, let's get some real feedback from the customer, right? Mm-hmm., right? Yeah. And then give them that. And so yeah, between these two, So come up with approaches, not a singular approach. Maybe one or two. And these are quick to mock up, I have to say. Right. I mean, it takes minutes to come up with this stuff in that working environment, you have to be okay with purposefully. As a product person staying out of it. Mm-hmm. and, and letting the development team talk to the users and get feedback that you expect is gonna come. I feel the, the more project managementy people in the room will say, Why are you gonna let the development team intentionally fail in front of the customers when you know that they don't want radio buttons or whatever, or they don't wanna drop down in their workflow that interrupts their workflow and then goes back and whatever. They just want radio buttons to quickly click through or whatever. Like you, the product person, highly suspect. I mean, I mean the, the aside from you should be doing some AB testing and running some metrics like that to get real metrics along the way before you implement your permanent solution. You might be in an organization where, again, sales vp, somebody else is driving you to be like, You gotta get it done by this date. You only have two weeks to try and implement. So whatever you can try and implement in this two weeks. Mm-hmm. is what you can do. So you don't have much time for AB testing. Like, again, these are, I'm not saying these are good excuses for shortcutting, the process. The bullet point here is, helping establish empirical product planning. In a complex environment. Okay? This is a scrum master by the way. So the scrum master is saying, I know the VP said they wanna buy XYZ date, whatever, Z date, Z date but the best way to figure out what these users really want is to do this AB test where we develop A and we develop B, and we push 50% users to a, 50% users to B and get some metrics. In order to do that, we have to implement A and B. We need to go through this process. So the scrum master has to talk to, in that example, the executives who demanded the feature, the users who are using the feature, both pool A and pool B, they needed to coach the product person. Hey, I know you're under a lot of pressure, but. The right thing to do in this scenario. Some AB testing, they need to talk to developers to make sure that the back end is instrumented to do AB testing, so Right. So, so the there is some block and tackling here on the scrum master part that quite honestly like I don't know if it has anything to do with Scrum Mastery in the first place, but it's like everything I just said is like, could be very critical to a new feature, you know? Yeah. And, and since we're talking about the role of a scrum master here, right? They should be doing those things and facilitating that, but the flip side of that question is who does it when they're not there? Oh, right. I'm gonna roll it into empirical product planning for a complex environment. To say if you've not previously thought about how you are going to measure success across your users across your environment, you roll this out to you really need to consider that as step one.. Before anything else. And this is the weirdest part about this is it's the scrum master bringing this to the conversation. Cause this is not something I would expect I, as the product person would expect to come from the scrum master, you know? Yeah. Hey, how have you, how have you really thought about if this truly solves a customer experience on Android, if this truly solves a customer experience on iOS so I'd say that that a lot of the examples that you've given in are of potential opportunities for a Scrum master to step in and, and, and help and be helpful are really going to require a lot of experience from, from a scrum master. And it almost sounds to me to some extent a lot of times this may be, this may be a scrumer that's more experienced, or ha has, has more longevity in product than the product owner, right? And so they're really being that crutch for a, a newer product owner or product manager. who does this when there's no scrum master? So the empirical product planning. That's so huge., I'm asking this question per category because there is a ton of people on the internet being super combative looking to, to, to pick, to nitpick and get views via low hanging fruit about this kind of stuff. Like, they're like well I don't see a need for a scrum master. No development team ever needs a scrum master is totally a part-time role totes-ma-goats! There's a lot of people saying this Sure. And repeating this on the internet. I mean, I guess you have to really lean on the product people to do this. If there's no scrum master organization, your, your product, people really need to sign on to. I'm going to defend my, my decisions and my entire team's decisions to try things and adjust depending on the outcome. I was gonna say fail, but that's so cliche to say fail quickly or whatever. But I'm really gonna defend my team's ability to try things quickly and adjust. I do this with my teams where I mark in the system of we are doing this task specifically so we can learn how this new technology works. I have a category for that, for work items. So I can track at the end of the sprint X percentage of our effort went into learning new things and trying new things. It's not gonna give you a deliverable to the business. It's just, it's basically like you can shuffle that into your training bucket if you again, if you have a training bucket. Yeah. I mean this is something that certain frameworks promote. Right. So innovation, basically architectural runway, stuff like that. Yeah, Yeah, exactly. Who does this when the Scrum master's not there? You mentioned the product side, but I've also seen. Especially on, on, on software development teams. the architects driving this, they would say, Well, we we're clear on where we need to go. This is, we don't have, there's a gap here. There's no scrum masters. So team, you're working on this now. Yeah. So the architect drives that. Sometimes. One hopes it's a temporary measure, but Yes. Seen that, I mean, I, I have seen in my career, I've seen team leads, development leads. What do you wanna call 'em? Yeah, just, just short using architect. Yeah. Architect could be just shorter. Manager. Manager. Development's a little bit too high level for what I'm talking about, but I, I've seen team leads or senior individuals on each team. Yeah. Do this. Senior devs perhaps is senior dev. Yeah. One, one or two on each, depending on the size of the team. I've seen them be tapped. To do this, but by the time you get up to a manager or director or whatever development, I don't think they really do this full time. They don't in the matrix environment, they're not even close to the team. Anyway. So when you are both speaking to empirical product planning, I just wanna make sure we're all aligned on what we are understanding that to mean. So when you say empirical product planning, what does that mean to you? Yeah, so for me that means that planning just enough product and then vetting what you've planned, right? So making sure that you're, you are basically coming up with evidence that what you're deploying or developing according to that plan is actually working for you. Mm-hmm.. If not, you pivot. That's what it means to me. Yeah, same. Yeah, yeah, yeah. So I was thinking evidence based. Yeah, yeah, yeah. So, and I was thinking a little more, maybe a little more broadly, so when I'm thinking about product planning for a complex environment, I'm thinking about things like roadmap and and even persona to some extent. We could get some empiric, some empirical information out of there. And then thinking about, okay, who's involved? I, I, I'll specifically think about roadmap. So when I was thinking about that from a product planning perspective, scrum master could be very helpful in facilitating Oh my gosh, especially facilitating that type of a meeting or planning. But if they're not there, that's kind of a large group of stakeholders. So we would have product and, and, and enterprise architecture and potentially user experience and developers and sales and marketing. I mean, who, there could be a lot of people involved in that. Sure. And so if Scrum Master isn't there there could be a lot of people potentially helping to establish that empirical product plan. And it could be we can really narrow that down from a roadmap to something far smaller and more measurable. Not sure. But that's kind of the way I was thinking about it. I don't think they're too far apart really from what we're saying. You know, I think my, my vision was something a little bit, little bit narrow than a full-fledged product plan. On a time horizon, it would be, Closer rather than mm-hmm. distant. Right. So more like coming up with features for the next PI or next few, few sprints. So we're getting into like huge contextual mapping. We, we actually talked about during road mapping for this podcast, . But road mapping is a whole separate podcast. the last category is facilitating stakeholder collaboration as requested or needed I brought this up in the previous podcast. where basically, your scrum master. Again, assuming they're a people person, we're gonna go out on limb and say they like talking to people. They have a extraordinary ability to extend the product owner for the team. Product manager, whatever you wanna call it, to coordinate and collaborate with stakeholders, to coordinate activities with stakeholders, talk to stakeholders, reach out to them and find out how they're doing, go back and forth with them, that kind of stuff. But also when I think about dealing with stakeholders, I think about dealing with users. And when I think about dealing with users, I think about this bullet point, facilitating stakeholder collaboration. I think about this bullet point as encompassing a lot of product discovery, Activit. Right. So talking to people, getting their input, figuring out the best way to, to collaborate with them to get their like clean input. Like true, their true input on things. Yeah. Filter out noise. Yeah. Filter out noise, that kind of stuff. You mean filter out to VP demands them stuff from the actual voice of the customer, Right. And to let the voice of the customer ring true. Product people probably are already looking for ways to do that as part of the normal job, but this is a scrum master helping with that. Sure. So like I already said, under the techniques, under the first bullet point that that techniques to, make a more effective product goal, , and have product backlog items to vet out, product backlog items. You're already helping with that, but now you're also helping. Facilitate conversations with stakeholders. So like this is the magic of the product owner's job on the team, right. That you're helping with. So what is the point of this bullet point? What is the point of facilitating stakeholder collaboration as requested or as needed? Like, is it you being a second person on a team apart from the product person who can basically do the entire job of stakeholder facilitation? what is it? This is being a side kick, I think to the, to the the product person, right? In facilitating specifically mm-hmm.. But what they're not doing is influencing the discussions they're facilitating. So how this could look in real life as simple as making sure that the right stakeholders are present in the sprint review and further, they're providing the input. They're not just checking a box. Especially nowadays, we're remote. You can't see the body language. So oftentimes what I see is stakeholders are invited some come up. Mm-hmm., most don't bother, and there's no enforcement there. A scrum master would say, Look, if you don't show up, we can't get the feedback from you. Right, Right. And if you do show up, we expect feedback from you. Mm-hmm., good, bad or ugly, they're enforcing those things. I use the word enforce, but you know what I mean, They, they're making sure it happens. Oh boy. That's the facilitation piece. I told somebody recently I was like, Hey, if you can't come to a backlog, refinement about the it that you were requesting, T I was like, it's cool, it's cool if you can't show up on, on the, my back. Over appointments happened on certain days. I was like, It's cool if you can't show up on a Wednesday, cuz you're really busy cuz you're an important person. That means since my sprints, start on Thursday, that means the next sprint that we can take your item into is gonna be two weeks from now. Yeah. Thursday. Assuming you can show up next Wednesday. Next Wednesday. Right. Exactly. And they're like, Oh no. Oh, whoa, I'll be there in a hurry cuz I want my thing to not go out in two. Yeah. So like that's it. I had that conversation. Because I'm the product person. I, I'm very happy to jump in front of my team and totally throw, throw myself on the grenade Sure. To, to, to make people angry or whatever. Also, I enjoy making people angry on the internet. Someone has to do it. It's a tough job. Somebody has to do it when Stormy's not doing it also. Yikes. Yikes. Also this is saying like the scrum master totally could be my hatchet man. If I need someone to be yes, for sure. I'm gonna say, So this speaks again to that just really close collaboration that, that connection. So the best teams that I've worked on, I have had such a fantastic relationship with my scrum master, and we do have the opportunity to play that good cop, bad cop, which needs to happen. Sometimes I need somebody to be the bad guy, and if it's a, customer that I, that I'm working with and I really need to keep a relationship with, and they're not coming to to the reviews. Yeah. It might be that I need that the scrum master isn't somebody that's new to them, that somebody that I am intentionally making sure that is, is at least known. Right. And it's for that purpose, Uhhuh, you know. And the other thing is particularly from a scrum master perspective, I think most often the interactions that I am experienced with my scrum master having actually are those facilitating those stakeholder collaboration internally. Between departments, between teams, between leadership, between sales, between marketing, between product owners, like whatever it might be. So certainly being aware of ways in which the need of the connections that need to be made and ways in which to facilitate those things. And who does it and if they're not, Yeah. Who does it when there's no scrum master? Every, everybody, because, so when we're talking about stakeholders, so no, everybody should, that anybody should, Well everybody in the sense the what is, who is a stakeholder, Like who, who is being impacted here? And that depends very much on who the stakeholder is. No. Who, who does, who facilitate. I mean, it's gonna be the product owner, because in this case, stakeholder is a very, very broad term. If we don't have a, if we don't have a, a scrum master, then the product owner is going to be the one best verse I think I, I hope facilitate. I'm, I'm gonna point out though, I hope so. But also I would say sales project managers, bas, bas executives I like this becomes real chaotic. Mm-hmm. when there's not a, a dedicated product owner to the team and the product like this becomes real chaotic to say we need someone to talk to a customer. A actually, the, the worst case scenario. Someone goes and does it on the product owner's behalf and then comes to the product owner after the fact to say, Hey, I promise X, Y, z sales does, does this a lot. Sure. Notorious for that. Yeah. Yeah, I agree. Nothing good can come out of that. There's no scrum master there. That's just break it that way. Well, but scrum masters aren't gonna be working with, I mean that's something that unfortunately is usually in my experience, handled after the fact a scrum master isn't working with, directly with sales. At least preemptively. The only reason we bring this up is because, to take us back to the top of the hour, people asking the question of what, what do you do all day? Basically, what, what's happening here is your scrum master is allowing for your product owner to be in more than one place at the same time. That's, is your organization willing to pay for that? And, and, and again, like we're talking about product stuff in this part of the video series, Right. We're, we're ignoring the fact that there are other, more, like more HR centric things happening mm-hmm. that the scrum master is also participating in. So now we're talking about the scrum master serving product. Okay. Ex serving and extending. And empathizing with the product people. Aside from all that facilitating stakeholder collaboration. why would you give that to the person who has all of the soft skills of dealing with people and really enjoys that? I can't imagine. Yeah, exactly. Who would do that? Yeah.