AA84 - Stakeholders in the Scrum Events

Here's a topic that you don't hear too often, , , who should be in your Scrum events as meaning team members, stakeholders, I guess product owners. anybody? Yeah. Who should be there. And also who shouldn't be there. Mm-hmm. equally important. Yeah. Who should not be there, Who should and should not be in your Scrum events? So, let's start off with the softball of the category. Yes. Let's start off with the Daily Scrum. The Daily Scrum, who should and should not be in your daily scrum. Hey, I also feel, while we're talking about this, we probably should reference the scrum guide. The Daily Scrum. Who should be there? Who should not be there? So If we're gonna start with the daily Scrum, I gotta mention the scrum guide and what it says. Daily Scrum is a 15 minute event for the developers of the Scrum team. If the product owner or scrum master are actively working on items. In the Sprint backlog, they participate as developers. Hmm. The developers of the scrum team. That includes the developers and the testers, so I understand it. So those people should be in the daily scrum. The scrum master specifically is deemed optional. So the Daily Scrum is for the team, by the team. People doing the work should be there to synchronize with one another. So what we just read was the Daily Scrum 15 minute event for the developers of the Scrum team. Okay. So that, that's who it's for. Right. So there's specifically, there's no mention of like other people or whatever in here, right? No, no other stakeholders. Yeah. Right. So obviously who should be there? The developers on the team should be there. if the product owner, Scrum Masters should be there. If they also have development responsibilities, they should be there. Otherwise, this is not going out to say that they shouldn't be there. It's just saying the people who should be there. I don't know if that specific tap dance is intentional in here or, Yeah, I think it is intentional. I think what. without paraphrasing them. I think what they're trying to get at is that the product owner and the scrum master can be present in a daily standup, but they actively participate only if they are working on items in the sprint. Right. So, I can see that, I can see why the Scrum mastery is there, because they. Yeah, they can be tapped for things that the team wasn't able to solve for themselves. The Product Owner can also perhaps provide clarifying guidelines on things that people have questions on. Why not? Mm-hmm., but it specifically does not mention any other stakeholders. Mm-hmm., right? so it's pretty clear as far as who should be there and who should not be there. Right. Developers should be there, testers optionally the scrum master in the product order, but nobody else. Yeah. So that's pretty straightforward okay. Now have you seen teams where the project manager is there and you know perhaps the resource manager is there as well to see how they're working? My resource manager is my scrum master. My resource manager is my product owner, right? My project manager is also my scrum master. I've seen a lot of stuff. Mm-hmm., I've also seen on teams where the. Development teams are made up of contractors, not not permanent employees in the organization that are only there for a air quote project. Yeah. Meaning a definitive start and end time. They just don't know exactly when that start and end time's gonna be cuz they don't know how long the project's gonna be. Right , I've seen the, whoever, the person that pays the bills, whoever the person that owns the budget, I've seen them. Kind of demand to be in the daily Scrum. Yeah. You know, Oh, I need to know what's happening. But usually it's a, the people trying to crowbar their way into the teams' day to day are usually the project manager type of people anyway. Only in the teams that I've been in. I agree. I I've been on teams where the, the project manager sorts would. I need to be there. Yeah. I need to be sure that work's getting done. And when they're not invited, when, when you push back, they say, Well, okay, can you send me, minutes of the meeting? Yeah. Right. It's like, no, no. That's a waste. Right , so who should be there now? I have seen in, in scaled situations where there's a dependency on another team mm-hmm. and it is perfectly okay for somebody from another other team to attend your daily. And vice versa. That is okay. They're not there the whole time. Meaning, meaning they're not there every single daily standup. They're there as and when needed. Yeah. They're invited for specific days when they're needed, right? Mm-hmm. For the expressed purpose of facilitating communications, getting clarifications on when those dependencies could be met , and that goes both ways for those that you are dependent upon and those that depend upon you. Yeah. So their purpose specific Yes. They're there for a purpose. Correct. Yeah. And by like, also part of that is like what's the self, self-managing teams? Oh geez, I forgot the name of the book. The book was called Team Topology Organizing Business and Technology Teams for Fast Flow. Matthew Skeleton, Manuel, Manuel Pius. Pius. Yeah. yeah, one of the types of teams in that book enabling teams would be an example of this. Say, Hey, we have somebody from our enabling team here today. When we finish, we're talking about an item that's kind of held up. They're here to unblock us or whatever. You know what I mean? Stream-aligned team, complicated subsystem team, enabling team, platform team. Those are the four teams. So enabling team. Yeah, so the, the,, somebody's there representing an enabling team or representing another stream aligned team. If we're talking about that team topologies book to talk about how your, what you are doing interacts with what they're doing, because maybe you are, maybe you're running in parallel and you're not necessarily working on each other's software, but maybe what you are doing, you have to either land it at the same time or what you're doing is affecting the end product together. Yeah , so somebody from their team is, is there to help you. That makes sense. But they're not. Yeah. You're right. Like you said, it's not like they're a permanent resident of your daily scrum. Right. That then, now that you've provided them, They're gonna be there forever. No. You know. No. They have to be invited in for specific purposes. Right. Yeah business analyst is an interesting kind of anomaly here. So oftentimes they're considered as part of the team and they are present as long as they're not anchoring the conversation in one way or the another. Occasionally you will have people in, especially in a matrix organization, you may have somebody from, if, if your, if your company has dedicated parts for things like DevOps, for instance, so on performance testing or something like that, you may have those people in, but again, they will be invited into your daily standup as and when needed. Right? Yeah. The case that I've seen more often here is there is not a dedicated scrum master and it is like the manager development or development lead or somebody. wants to be in every daily scrum for every team that they have, people that they manage on. Mm-hmm. because they need to. be watching or what? You know, like I don't, Some sense of control. I don't know. I don't know what that's what it is, that they need to be sure that their people are delivering value. Right? Right. That's just another way of saying that they're controlling need, be watching over their people. Oversight, providing oversight. That's what it is, Right? Oversight , but you know, like is there a way to gracefully. Help them understand that that's not necessary. Yeah, I, I think there is, I think when you, when you have your calendar invitation for the daily Scrum, I'm assuming most people have some remote component Right. to their teams. So there would be a, a calendar in, in that calendar agenda, you make it expressly clear that this meeting is for the team. By the team. Unless you're working on something on the backlog, you do not need to be present. Unless expressly invited, Oh boy. And then I've done this , feel free if somebody is persistently showing up to Uninvite. The first thing here I would suggest is to have a one on one with that person and also, just so it's clear to also have a one on one with that person's boss if possible. Cuz again, if you have somebody that's popping in chances are they know what they're doing is not, not. Desired not. I was gonna say they know that they're coming in uninvited. Yeah. I was trying to figure out a nice way to say like, gate crashing your party. They know they're not invited to the party and they're showing up anyway. Yeah. This one like the, the way out of this, because you're gonna deal with this in every single category we're about to talk about. You're gonna deal with this issue. Yes. You have somebody in management. Who, because they are vested with the power of management, they feel they can show up to every party uninvited and will be welcomed with open arms. And no, nobody has the ability to say no, they must force their way into every situation. Let's, you could ask them what is your objective in attending this meeting? What do you hope to get out of this? Right. Inevitably it, it boil down to, you know well, I just wanna make sure that the event is happening properly, that people are working properly, et cetera, and then it quickly degenerates too. Well, if I'm not there I'm okay with that as long as you send me minutes of the meeting. and then you, what you say very politely is this is for the team, by the team. So if the team feels like they need you, they'll reach out to you. Mm-hmm., right?, and yeah, just uninvite them. Be brave , yeah. Yeah. You're right about being brave because people ask, what is a scrum master Do all day? Like this is part of what you're doing all day. Like you have to deal with these organizational things. And some organizational things might be one specific person being the roadblock. In the organization. I say uninvite them, et cetera, that specifically applies. I if they're just there kind of fly on the wall and they're not really saying anything. No harm. Right. But oftentimes that's not the case. Oftentimes, they come in and they're asking people questions, especially if somebody says I didn't get as far as I wanted to on this issue yesterday that I was working on. I ran into a roadblock, and they immediately jump in, What have you done to solve that? Blah, blah, blah, blah, blah. If they're coming in and, and interjecting in any way that gives you full license Yeah. To eject them from the meeting. Yeah , I like, I wanna move on cause we have so many other sickies and I feel moving fast. I, I like, I also wanna keep going this topic. I don't know if we should take this topic offline under the banner of something about like dealing with , organizational roadblocks that might be people something, something along those lines. Yeah, because there's a coaching process to be employed here. You know, start, start one on ones with them. Start one on ones with, with your, with with their manager. One on ones with your manager, whoever that might be, but basically one on ones with whoever can break down these problems that you're experiencing in the organization. And I use problems loosely because problems might be, it might be one person, honestly, it might be just one single manager development who just needs to be everywhere all the time. That's how they feel that they're. If they're not everywhere and in every conversation, they're not doing a good job. That's just the way they feel. Yeah. But because they're everywhere, they're not actually, they're not actually doing, They're doing anywhere. Yeah. They're not doing anything. Yeah. It's, it's, yeah, you're right , manager development. And also sometimes I feel architects jump in and they'll come in to the Daily Scrums specifically, and they'll start directing people. Yeah , and that's just disruptive. It portrays the. You know, the atmosphere of mistrust, right? And people feel guilty. they're being told you shouldn't be doing things that way or this way, and that kind of thing. And calling them out in, in front of their colleagues. Those sorts of things are not really conducive to forming the team and keeping them well well synchronized, again, I would just say clear agenda. Just say if you're on this meeting, it's because you're working on, so, In the sprint. Mm-hmm.. And then if they gate crash your, your meeting, ask them. Or are you working on in the sprint or you're not? Okay, well maybe you don't need to be here and we'll give you some time back I don't know if this is typical of what people experience, but I find that on the, on the, some of the more high functioning team, I dunno if that's the right way to say it. On, on some of the, the, the best teams that I've been on out there the, the actual conversation that happens at the Daily Scrum again, as long as people aren't asking the product on our questions, and as long as things aren't being taken in and out of, of the, of the sprint and stuff like that, and the developers kind of have a, a, a decent grasp of the, the concepts of Scrum, they can kind of move the event along. What I'm trying to say basically is the scrum master and product owner basically are silent most of the time, and the team kind of moves through it the best meetings , like they're so low level in the weeds that most managers or whoever would come to these meetings would just be bored, lost. Yeah. It would just be bored. Either bored or just lost, or I mean, even another developer from another team like. They don't know the ins and outs of every single work item and every single piece of the program. I, I could see where a maybe a manager or a lead or some, something, basically a, a developer who used to work on that piece of the code, who doesn't work on that piece of the code anymore. They might feel like they want to interject and be like, Why are you doing that? What is this? What did you try this? Like, I can see that. But also if they're not on. The easiest way is just don't invite them. If they're not on the team, they can during the reviews or maybe Other things outside of this code Reviews, maybe in the sprint review? I don't know. They can have their say Sure. Get Yeah, right. Get what they need but also the point of the meeting is for the developers, so look at what they're doing and realign. Change work items, change the direction of what they're doing and figure out the best way to do the work, you know? Hey, I did this in the code. I got this PR in. Oh, I looked at your, I did a code review on your PR and I, you're, you're using this method. Are you sure you want to do whatever and not do use this way of doing whatever? And it's like, Right, I could give a shit about what you guys are talking about, PRS and fucking methods or functions or whatever. That's what they should be talking about in me. They should be, they should be synchronizing. Cuz somebody's gonna say, Oh, you're doing that pr Well why don't you wait a little bit cuz I have something in there I don't wanna, Yeah. Right. Yeah. You know those, those are the conversations that's gold right there. So yeah, I agree with you there. Yeah. I need you guys to clear that PR outta that because I got one directly behind it. Oh, I didn't know you were working on that now, or you., You're right. Yeah. Yeah , let's , let's, let's move on to the next event. Where Elmo, Yeah. Let's move un uninvited guests might show up. Yeah. Let's move on to the next one, which should be our quickest category of this whole series, which is the retrospective, the sprint retrospective. It's gonna be just as quick as one of the other categories that's coming up too, I believe. So. Retrospectives, Again, the whole purpose of that is to look at the way the team is working., if you look at that and identify opportunities for improvement. So if you look at that as the objective of the meeting, then who can really, who can really participate meaningfully in there, except for the team doing the work. That's it , yeah. You know, so any other stakeholders that come in and, and on our way in, they should be very, very actively discouraged to attend these things. Yeah. When I'm a scrum master, I. This one is not open to debate. It's like, I there a lot of these even the daily scrum. Right that we just got done talking about that. I promise I'm not gonna spend more than 10 seconds talking about again, but even the daily Scrum like you said, like you pointed out like, hey, you got that manager, you got that development lead, got whatever, that executive or whatever it is like demanding to be in, Hey, sign me on all, all the guy that pays bills, for example. Right. Sign me on to all your sprint events. You know, usually when I hear that it means I'm getting replaced. That's what I sign me on to all your events. I'm like, Uhoh, yeah , But the retro if you're signing onto the daily Scrum and you're gonna be cool and you're not gonna say anything and you've proven that you understand the point of the meeting and you're gonna play along with the rules. That's cool. And I'll let you stay for a while at least. Right. I'll let you stay retro. No, there's no room there. I'm gonna, I'm gonna cancel the series of meeting. I'm gonna reinvite the team. And you're not gonna be on the new I'm gonna use a new link. It's gonna be invite only. You can't add people. I'm gonna be real hardcore about the retro. I agree fully. I mean, the real fundamental reason for that is not just because it's for the team, by the team, et cetera, but you really wanna promote a safe environment for the team to talk about anything and everything. And they will not speak up if these external parties are present. That's right. So you want those people not to be there. And by not being. That's how they're helping. Mm-hmm., right? So oftentimes they'll say, Well I just wanna see how I can help who, Here's how he can help. Don't show up, please. Right. You're helping if you don't show up. Oh man, if I had a nickel for every time someone told me that Ooh boy. I have at least three nickels , so like, the question here is like, well, how many Oh, you might need me, Mr. Development lead or whatever, to help unblock you with some of the actions outta that. Retro was like, Well, cool. Then the Scrum master can take the action outta the retro and bring it to you. Mr. And Mrs. Stakeholder out of. The session. Absolutely right. But inside the session, even the injection of one individual who's not on the team, one manager, one executive one, and Nullies the event team. Yeah. In my view. Right. Yeah. Well it nullifies the whole, the whole environment the whole air of psychological safety that you're trying to establish. The whole atmosphere of psychological safety you're trying to establish. Could potentially be nullified by just bringing one person who is not responsible for any of the work into the team as they talk about, you know? Yeah. So I, I, I will say that there is. Potentially, potentially an exception to that rule we just outlined, which is occasionally a scrum master might think about having somebody completely from outside the team. Mm-hmm. coming in and facilitating the retro script another, another scrum master maybe. Yeah. Right. And that I've tried this before and It's amazing because they will open up and talk about things with someone else completely, even though they're a stranger, because that stranger has no background on this, so they're just gonna be asking questions directly. Yeah so I think that might be the only exception is you bring someone in for the express purpose of facilitating the retro. And if you do that, make sure that you as a scrum master are not in the room. because why bring someone in if the team's not gonna be able to open up? Right. If you're there. So make sure that if someone's standing in for you, you stand out. Don't come in. Yeah. Interesting. Yeah. Yeah. I was thinking about mentioning that one, but I also was thinking about moving on from Yeah. Let, let's, let's do that. Yeah so retrospective, that's fairly straightforward. Again, the most firm stance I'm gonna take on any of these are in the retrospective. So there we go. I just took it the sprint review. Yeah, this is kind of the opposite , so sprint review is where transparency really plays out, right? The team saying, Here's the fruits of our labor, here's, here's what you trusted us to work with over the last two weeks, and here's what we came up with. And so with the sprint review, Anybody pretty much is welcome. Now, having said that, you absolutely want certain class of people in there, group of people, you want your stakeholders in there because you want their feedback. You also want something else that's important, that's often not done very, you know? Clearly, which is explicit, implicit approval of the product increment. So you're showing something, you're getting feedback. Mm-hmm., and then you wanna know if you hit the mark or not. Yeah , if you didn't. Okay. So get that feedback and maybe create some work items in the backlog if you did get that feedback explicitly. If possible. Mm-hmm. just say you accept this, right? Yeah , and then you're. The team knows where they stand , but yeah, Anyone's welcome to the Sprint Review, in my opinion. Yeah. This, this includes anybody in in a matrix environment, a manager, resource manager, whoever it is. You're all welcome. Right. Just let the event play out. So let the team show what they did. Yeah. Right. My only interjection with this one about everyone's welcome is that, so the scrum guide specifically points out the Scrum team presents the results of their work to key stakeholders and progress towards the product goal is discussed. Mm-hmm.. So if, if it's key stakeholders, I mean, they really leave it open ended, right? But key stakeholders to me, . Like we were talking about before when we were talking through the daily Scrum, if you have your development lead kind of chopping at the bit to know what you're ah, I need to know the ins and outs of what you're changing. If you have your architect kind of bouncing in to say, Oh, are you using are you using this? Are you using that? You know, are you using this table? Are using queuing, are using whatever. Right? again, to me in the product, if I'm inviting people and I have the opportunity to bring people, , I am trying to bring customers as close as possible. So all those people with a stake, stakeholders with a stake, right? All those people who, who want to influence what the team is doing, right?, people I typically think of as middle managers in the organization. All those people who want influence into what is happening. They can all come however, to me, the murkiness of the language used here in the scrum guide kind of waters down that I need my customer's input feedback. I need my customer's feedback first, and then everyone else can dogpile it on top of it. Like, the lines of, of, of communication. I. Them to be a little clear. I need, here's my, here's my first line of communication straight to the customer, and then my second, third, whatever. Now I'm ready to hear from the architect and the internal manager and the resource managers and whatever else. Executives what? Cause they have their own sessions. They do. You know, they do. That is gonna go there. Right? So if the architects and all these people are giving feedback, does that really belong in a sprint review? Because you really are there to. Like I say, the fruits of the labor, Right. Of the team and get feedback from key stakeholders. Customers would be the quintessential key stakeholders. Yeah. Great. Yeah , perhaps the people that are paying for the product project, Right. Could be sponsors , yeah, so they would be your primary audience right there. And then maybe after that it could be a separate meeting with. In, technically in nature, I imagine, right? Yes. With, with q and a type of things with architects, I would say there's some murkiness there, agreed. Right? So for example, if your key stakeholders are what they are, and then you may have people from NIS right network information security in there. You may have compliance people in there. They're not directly your key stakeholders, but they're questioning. Yeah, because you are now saying this. Accepted by the key stakeholders, therefore it's ready to go to production. Mm-hmm., if it's ready to go to production, they are entitled to ask you those questions. Has it been vetted, et cetera. Right. Do you have the right blessings from these different, organizational entities? That's fine. So, so in that case, they're also stakeholders because they're asking these questions. Yeah. Fine. Entertain them. Right. That's okay it is murky , and it takes some time to get it right. Yeah. For any group of stakeholders. I wonder the, the process of this, let, let's say for example, cuz we, we don't talk about this enough on the podcast either. Let's say for example, you're, you're making software. to be the B2B software to be used by customers that, that are not internal only, like actually meant to use by Sure. So there are people paying for features to be developed. Right. So in your sprint review, you probably have representatives of the users, customers, meaning customers, users, but also you probably have a, a, maybe a rep, maybe one Usually don't get more than one of this type of, this class of stakeholder. of the people that are paying. Right. So now you have, because B2B software, usually you have two classes. You have a class that is paying for the software, and class is using the software. So Right. Hopefully you have at least one of. Oh, maybe more, maybe more users usually than the person paying. But the idea is you'll have the customers on the part of the call, right? And they'll have questions and they'll have things they wanna talk about, and it's okay if they talk to each other, whatever. But then that, that whole grouping of internal, like when you get done with them procedurally is it cool to say like, Okay, we're done with the first part of the meeting, and then the customers drop off and then you continue with the in. People, I mean, I would hope that you don't have that many requirements where you have to where with the same features you have to serve two different personas, right? The internal persona and the external. I would hope that you separate your stories, but would you do some kind of. External sprint review, internal sprint review. So you can separate the audiences, or we just add 'em all together and let everything come out in one. I prefer the latter , and here's why. So let's say in that scenario where you have. The two classes of stakeholders you mentioned, the users and people paying for it, the external ones, let's say, right? Mm-hmm.. So if you're in that same event, you can certainly show what you've done, et cetera, get feedback, and then the internal ones where architects or others maybe asking about some technical debt refactoring et., I'm fine with those other people also hearing this. Yeah. Because what it does is, at least from my perspective, is it raises their confidence that we're improving the quality of the product. Mm. Right. So I don't have any issues with them listening. And plus the other thing it does is it sets their expectation on what can, how much can we deliver? Right. Because we're also spending time on improving things. Yeah. Not. Delivering things. So I'm okay with that. So one meeting would be my preference, but again, the scrum doesn't dictate that. So if it works better for you, it's separate ones, then fine. Well, I think that's more a cultural thing more than anything. going back to the last podcast we talked about, like I, I certainly could see some, some risk a. Managers in the organization say, I don't want to talk about any shortcomings in the software in front of the customers. I don't know but like come on. Are they like, they use it every day, like a they would know you would. Yeah. Yeah , Okay. Well, the sprint review. So the sprint review is kind of the, that's the one where I, I, I really don't have very many stances at all. A a little bit of organization, the only kind of somewhat of a firm stance I have for the sprint review is I need the customer channel of communication. I need to hear that. So anybody else is there is fine. No problem. They can be there, but they need to un It's kinda like the daily, the daily scrum, like right. You can, you can show up, but remember like, I need the free flow of information between developers. That needs to happen between the customers and, and myself product. Right , if anybody's jumping in in the middle of that, or distracting, that's gonna be a problem and we're gonna have a one on one to deal with it. For sure. I agree. Absolutely fully. It's not, you're. You know, it's, it's not gonna be a one on one with a scrum master. It's gonna be a one on one with product to say, Hey, you're, you're disrupting me. You're making it difficult for me to get what I need in product, which is That's a whole different podcast. Absolutely agree sprint planning. Sprint planning. Goodness , this is quite a long event , let's see, in terms of time, let's see what the scrum guide says. Yeah, let's see what the scrum guy says. Product owner ensures that attendees are prepared. The Scrum team may also invite other people to attend Sprint planning to provide advice. So this, this is where I think about people like, you know say performance testers or other external skill sets that you don't have on the team necessarily. Yeah. That you need for that sprint. Mm-hmm.. So there wouldn't necessarily be standing participants for every sprint planning event. I would think. Right, Right. You would just bring them in as you need them. UX is another example , ui ux people, if you need 'em, bring them in. Yeah , so yeah, I, I think this one is also fairly straightforward. Sprint planning. Anybody, again, anybody who's going to be working on items during the sprint have to be there, which is your dev team , testers and facilitation wise, the scrum master typically is, your, your business analyst is there if you have those, but yeah, external folks can be there , testers performance testers and the likes. Architects, maybe. Mm-hmm., if you need architectural guidance security or compliance people, if you need their guidance, Right. Yeah. They can be invited , but again, they're not standing participants for every event. I have typically done the sprint planning in two parts. I, The first part is what we're gonna try to bring into the sprint. Well def, well, actually the first part is defining the goal, negotiating the goal. That's a better way. Yeah. Negotiating the goal and then figuring out what we're gonna bring into the sprint. The second part is how we're gonna take what's in the sprint, How we're going to develop it. Yeah, like the plan, the low level plan, so, when I think about saying like, well, this is a pretty open event. Like it's it's kind of open to everybody. Like if you break it in half the second part where it's just the developers figuring out how they're gonna plan work. Yeah. They can reach out to, to people in the organization bring in to talk about whatever they need. Basically, the development team members, while they're breaking the work down to figure out how they're gonna implement everything, to basically have access to. Whoever they need to have access to in the organization. Right Back when everyone was still working out of an office, usually, whether, like for me, this was like a Monday, we would do this on Monday afternoon would be the sprint planning. Be lunchtime, they'd carry your lunch, we'd kick everything off, and then you'd be there until everyone went home. You'd be in the room until everyone went home. Mm-hmm. and knock it all out on a Monday. And that, which is, that was the only team that ever did Mondays for me, , like the rest of my career. No, no. Every, every other team has avoided Mondays like the plague. Sure. But they, but they, they did it on Monday, worked for them, and they basically would take over a conference room with the whole team and then they would, everyone would know that it. Dev team's doing planning. It's Monday morning, Dev team's doing planning. Everybody knew, or Monday afternoon, I'm sorry, every dev team's doing planning and they would go pull people back in the room. And, and for the second part, for the, how the product owner would leave, they'd still be in the building so they could still get them and bring them back or call 'em on the phone and tell 'em to come back. But they wouldn't be in the room. This is a, Yeah, yeah. This is, that was a pretty typical thing with, with that team though. Yeah. That's when the team's figuring out the how. Right. So, yeah, I agree. But, but the first part I remember like we did some work for the financial accounting people. Sometimes we brought in customers, sometimes we brought in sales people, depending on what things they were selling and whatnot. Sometimes there was other executives or sometimes we'd bring in people from marketing if we were trying to do a feature that they were launching on a certain date. I guess where I'm going with this is there was a lot of coordination throughout the business to say, Hey, these features are at the top of the back. We think these are the ones we're gonna talk about in the next sprint. Mm-hmm.. So can you be ready if we call you to come into the room at this block of time? Yeah. Right. And if not in this block of time, then let's, let's put on something, on a schedule that's in the block of time specifically to get you in the room. Talk about So, in places that I've been that did not have a dedicated scrum master on the team. A lot of that fly by wire coordination, figure it out on the way, like the product did a lot of that and product becomes a. Like very overwhelming when you're trying to do all this discovery stuff. Figure out the future, the meet with customers. Drum up business. Yeah. Kind of working with sales at the same time, and also doing the team activities and also trying to schedule everyone at the same time. And it's, it's, yeah, it's too big a lift most times, right? Because. Product side of the house for most organizations isn't all that well matured, let's just say. Right , but yeah, I, I think that's fairly straightforward as well. Then when it comes to sprint planning, right? Yeah, yeah. Get, get whoever you need to make things happen. That's the key. Who, who do you need? And it's not the same people every sprint planning necessarily. Yeah. I, I mean, other than obviously the product owner and the dev team. Right. It does change. Yeah. Well, it does. Well, exactly what I just said is some sprints, you're trying to launch stuff for marketing some sprints. You're trying to, to help sales with the commitment they made some, you know what I mean? It's different, different people. Yeah , different things and different sprints. Yeah for those teams where I have been the only product person and there has not been a scrum master to extend and help me with all this alignment, basical. I try to shift as much of it as possible into backlog refinement. So all those questions are worked out before we ever get to sprint planning. Yeah. Yeah. And, and that, what I find is that makes backlog refinement. Like I don't, Let's, let's see what the thing has to say about backlog refinement. I don't know why. I'm always, I'm always shocked that doesn't say anything about backlog refinement. I think the word refinement may only occur like once Product backlog refinement is the act of breaking down and further defining product backlog items in smaller, more precise items. This is an ongoing activity and adds details such as description, order and size Attributes opt often vary with the domain of work. Developers who will be doing the work are responsible for the sizing. The product owner may influence the developers by helping them understand and select trade off. So yeah, the product owner working with the developers and the scrum team, product backlog refinement, even though it doesn't specifically. The scrum guy kind of skirts this, but again, the more stuff that you push off into the backlog refinement, the quicker your sprint plane's gonna go. Yeah. my opinions on this have kind of been softened over time., because I've done backlog refinements on a schedule same day and time, you know what I mean? Same length of time box or whatever. I, I do them at the same place at the same time, and that's one method. Other backlog, refinements have been completely ad hoc. As soon as we see a need for something, I'm just gonna look at people's s find the next spot, and boom, I'm gonna take it and we're gonna do some refinement. If the developers feel they need to do a bit of solutioning to kind of feel their way through it, hey, whatever. Like we'll get there, right? Sure. You know, and all that work. If you were really a stick. For financial accounting of times and capitalization, stuff like that. There is a way you could take the time spent in backlog refinement and the time spent in sprint planning and roll it all together and say, this is the same planning time. It's the same bucket. Yeah, yeah, yeah. It's planning time, right? Yeah. But for, for easily 90% of the shops that I've been at, they don't do that level of granular Yeah. Yeah. They, yeah. They don't analysis on people sign, They just don. Yeah, so, so I, for backlog, refinement, whoever your audience is for the sprint planning. Could also be the same audience for backlog refinement. Absolutely. Yeah. I mean, it's whoever's primarily, the biggest group there is the group of people doing the work. Yeah. Plus the product owner to explain the details of what the work is. Mm-hmm., and then you add in those external influences that as needed. Right , so I agree. Yeah. It could be the same audience. The the sprint planning process in SAFe is a little bit different when it comes to big room planning where you have multiple teams doing things and then they synchronize and they go back again into their own breakouts and things like that. Yeah. But ultimately the attendees are largely the same. Yeah. have you ever done backlog refinements where only part of the developer's like only a developer or two or three or whatever? Like, Yeah. I don't know if it's, I don't know if it's like, You just throw the invite out to everyone and mark everyone as optional or just pick one or two people per week on rotation or just, just a senior people? I, I, I don't, I've never come up with a good Hey, this is a system we're using where everyone doesn't feel, I like the way I feel. Tobacco requirement says you can throw everyone on as optional, but people feel like if they don't show up to the back law refinement, they're gonna be left out. Having either having a say in the work or understanding what's happening by the time sprint planning rolls up, because at sprint planning time, we're looking at items that potentially half the team has already looked at, already potentially speced out the acceptance criteria already understand. So yeah, it'll put your developers in a spot where, let, let's say, let's say you have a five person. And three people participate in all your backlog refinements. But then those other two people show up to your sprint planning and now they're like, Wait, what is this item? Right? What, what is it? So they're seeing it for the first time. So like on one hand I see a reason to say, Hey, backlog refinements you don't wanna show up. That's fine. No problem. Like we'll have another shot to show up at Sprint Planning review. Re-review. I'm trying not to say Rereview re-review. re review. Yeah, Review again. what, what we did for planning cuz. Cause we'll likely we have the business description written out. The exception Criter criteria may be written out , maybe the developers have kind of specked out some subtasks based off of how. The high level might think they wanna do, Maybe they sketched some stuff, a whiteboard diagram or whatever. I mean, took a picture of it and then the two developers who weren't in any of those sessions will come in and say, Well, I don't, this is not the best way to do this, maybe. We'll Yeah. I don't know if, I don't know if that's even worth. Bringing up is a concern. I think that's all normal. Part of the normal, like I think it's, it's horses of courses. Teams have to figure that out. Some teams rotate who goes to background refinement? Two or three people that go and they rotate. Yeah. Some teams say, Well, the tech lead, that's it. We don't need anybody else. I've seen that. You know, and, and to your point, yeah. The team is at a disadvantage when it comes to sprint planning. They end up essentially repeating things, right? So they're basically not as efficient cuz you, you're repeating things for the people that weren't there, so you may as well get everybody in, right? Yeah , so yeah, I think good practice is to get everybody in and get through it as expeditiously as possible, rather than repeat the thing. Yeah. Well that's that's backlog refinement. I mean, we just went into more detail than the scrum guy does and backlog. Refinement. We did, Yeah. It was still pretty high level. It's like, whatever you're do in sprint planning, you're basically gonna do a very similar thing in backlog, refinement so we reviewed each of the Scrum events , we kind of talked about stakeholders in each of them, who, who should be there, Some of them we talked about who shouldn't be there, and. Yeah. Any closing thoughts, final thoughts? Let us know if you come across specific challenges or share your experiences with us in the comments below. And don't forget to like and subscribe. Share your stakeholders in the comments below.