“Q”

Hi, welcome to the Scrum Sessions Podcast. This is episode three. I am Q here in Dallas in Texas with my good friend Gereon.

Gereon
Hi everyone. I’m in Berlin and it’s very good to have you ever seen again.

“Q”
So it is all three men, we need to the first to write. And I learned how to edit video, which I never did in my life.

Gereon
And I think we beat 90% of the podcasts out there, which never make it past episode three. So yes, we’re already Yeah.

”Q”
I mean, we just need one more and we are good. So, you know, honestly, I was thinking what? I don’t want to do this too scripted, as you pointed out in the past, so I was like, what you’re going to talk about an episode three, right? We have the first two we have Jeff. Jet. Jeff can talk for five hours, you know, but so what’s your going to talk on episode three? anything on your mind?

Gereon
Yes, refinement, please. Because this is always an issue that drives people up the walls. And I think we can add some value to listeners.

“Q”
Okay, very good. I like refinement. You know, refinement is one of the big things for me. Because, honestly, I don’t know, what’s the problem with people and refinement? And I’ll tell you, I had hundreds of teams in my not so illustrious career, right? I had hundreds of teams, I had the best the biggest I’ve ever had was 350 something. Okay. 354. And before that one, I had one with 122. And it’s normal for me to have at least 40 teams. Right. And I don’t I can tell you, I don’t remember when I saw a team who did refinement. Okay. But you’re not very efficient. Right. So I think it’s a great topic. I think we should definitely talk about that. And you probably have different experience than me. But this is what I noticed. People who cannot refine are not very good at Sprint Planning either. Absolute Absolutely. There’s one thing one thing leads to another right if you don’t if you don’t refine Well, well, your planning session, I believe the scrum guide says planning can be up to eight hours, right? Well, we’re going to end up having an eight hour planning session. Yay. Right. Yay. Scrum has too many meetings. Yeah, I know. I know. It’s usually because you don’t do it. Right. So where should we start? About three, five minutes? What’s on your mind?

Gereon
Well, actually, I think you’re pointing out a very interesting thing. And a lot of people aren’t aware of it. There is a very close connection between refinement and sprint planning. If you do one of them, well, especially if you do refinement, well, you sprint planning is going to be really easy. But because people for some reason don’t like to refine or are not good at it. They have the super painful sprint planning. And so if you are in that situation that your sprint planning to take too long as super painful, then maybe you don’t solve the sprint planning directly. Maybe it’s the refinement that you need to look at. Right. I think that’s one of the first things create that awareness that actually those two are connected, and maybe you have to go a little bit upstream to solve that problem in the sprint planning.

“Q”
Yeah, absolutely. And one of the symptoms that you can tell how connected they are is you get to a sprint planning session, which honestly, most of my teams once they get refinement done well. It doesn’t take them 20 minutes to plan for a sprint. Exactly. It’s a matter of a we can do this much. We have this much capacity. And we’re done. Right? That’s pretty much it, right? I mean, you have to write the sprint goal, but it’s 20 minutes, right? 30. If, if you spend 10 minutes Hey, guys, how’s your week and all that stuff that may get to 30? Right?

Gereon
Yeah, with one with one caveat, though, if you are in situation in an environment where things changed drastically from one week to the other, you might need to check in if something has changed, that would, you know, change the clock, right? But for most teams, it’s actually the case, right? You’re done in 20 minutes, because everything is already clear. You just talk about the sprint goal. You do the commitment and you’re done. And this I think this idea feels very strange to a lot of Scrum practitioners because they know the opposite. They know the painful sprint planning everybody dreads going into that meeting. And yeah, it’s due to a lack of preparation during refinement before

“Q”
Yeah, it’s a it’s a good point. And honestly, a classical symptom. I see this all the time. You go to sprint planning and people open every single product backlog item and start discussing them all over again. Or sometimes it’s the first time they’re discussing it which is even worse right? And then oh my god, but cute. Did you notice that took an hour and six minutes I kid you not for one backlog item during sprint planning because nobody even seen it before. Right? So Your point, a connection, right if we don’t make the connection, right, a lot of people complain that scrum has too many meetings. I don’t think that it’s a matter of too many meetings is too many inefficiently run meetings that caused the problem, right? Yeah. Some of the things that you would, you would recommend a teammate. Let’s forget planning for now, right? Because we all agree that we, the problem is usually and refinement. Right. So let’s talk about planning right now. What what is one of the things that you would recommend teams look for in refinement, or I don’t like to use the word practices, because that’s dangerous, right? But what what are the things that you should be aware, during refinement to make it work better?

Gereon
So actually, the one thing I always try to get across to teams is not actually how they run the refinement, because to be quite frank, I really care about that. It’s to have it because I totally get it refinements can be super boring, right? They can be too detailed, they take up a lot of time, and you want to work on something, you know, the sprint is already running, you have a lot of pressure. And so you don’t want to think ahead of the next sprint. But I always like to bring in some comparisons to that, right? So we’re talking about sprinting, in a sprint right, meaning running very fast. Now, if you look at the Olympics at the 100 meter dash, for example, right? Do you think the people running the 100 meters? They get to the starting block? Do you think they are prepared? Do you think they have refined everything before? Of course they have, right? They went to the toilet beforehand, they have prepared their shoes, they have eaten the right way they’ve been drinking the right way they’ve taken their electrolytes and so on. So if you want to sprint, you have to be prepared. Or think of a restaurant, right? So imagine a restaurant only has dinner service, right? They open up at 6pm? Do we really think that the first employees are going to arrive at the restaurant like two minutes before 6pm with basically together with the customers and then as you enter as the first customer, they are going to, you know, start start vacuuming the place. And so no, they’re not, they’re actually going to do food prep, like six hours, eight hours before they even open the restaurant, right? Because in other context, this idea of going into a situation where you have to perform quite quickly without any preparation is crazy. It’s ludicrous. No restaurant is like that. And still teams think they can, like run can run their sprints like that, right? So getting that understanding that you need to do is it is absolutely critical. And in addition to that, think about the fact that you think about the situation where you don’t do any refinements, right, you just do the sprint planning, you go in there, and you find a dependency right now. Now what do you do, right? You say, Oh, well, we should have talked to the graphic design guy first or the IT architect and so on. And basically, you’re already stumbling into the sprint, the sprint is about running quickly. But knowing you’re not going to because you will start your sprint by stumbling into the first couple of days. Oh, let’s see if we can still raise the IP architect. Let’s see if we can get hold of a graphic designer, right? And they’re gonna be busy, right? They’re not going to be instantly available. And so I think this is really important as Scrum Masters and as product owners to drill this into the hands of the of the team, that they are actually self sabotaging if they don’t do refinements.

“Q”
Yep, that’s a great point. And you see, actually to build up on this point, you open a great, a great, the barn door is open right now about something, you know, is the preparing. So the same way you have to prepare for planning and refinement is a way to prepare for planning, right? You also have to prepare for refinement. Because one of the things I noticed over the god knows how many years I’ve been doing this. People parachute things during refine, they say we’re going to do refine, right? Everybody gets in the room. Well, these days, we don’t get in a room but we get in a virtual room, right? And next thing go no, okay, this is the first backlog item we’re going to look at. Nobody had any idea that was coming until the moment they got into the room. So there you have it. Oh, hold on. I need five minutes to at least read this stuff. Okay. And then. Okay, I have questions now. And then let’s see you actually made make some progress with this. I guarantee you because they didn’t prepare for that. It’s going to come to planning, they’re going to pull that story and say, Can we open this again, I forgot to ask this when we did refinement. So one of the worst things you can do in refinement is I call parachuting, right? Just drop some stuff in there and hope for the best right? We always have to have some level of preparedness, some level of planning, whatever we do, right? The same way you should prepare to planning by doing refinement. You cannot call refinement. meeting and say, Hey, guys, let’s talk about this stuff. Right. And it’s the first time that anybody’s seen it. That’s one of the things that creates chaos.

Gereon
Yeah, that’s a very good point. And I think I can even do you one better. And that’s the situation when you have that plus, the product owner doesn’t have orientation into what she wants to do next, right, because even the parachuting, you can do it with the product owner coming in, and she knows where she wants to go, right. She says, Okay, this is the direction we’re heading. Let’s look at some stuff. And it’s the situation that you described. But sometimes the, the product owner doesn’t even know, right, the product owner is confused, doesn’t know where to go next. Because she hasn’t done the upstream work of orienting herself towards what the stakeholders want, or the customers wanted to actually know which direction to go into.

“Q”
Yeah, and honestly, that’s a great point. You know, again, the barn door is open again, for another great point in there, right? It’s, I was teaching product management about two weeks ago. And they spent almost half a day in product management talking about prioritization techniques. Right. And I mean, that’s all right. It’s the most I talk in two days, right? A whole half a day’s isn’t about this, because I seen over the years product owners have a hard time prioritizing, right. And I seen in backlogs where they have, this is the top priority. And these three are the second priorities for the third priority, right? Because they have a hard time. And another thing I noticed is when you teach them several techniques or prioritization, they think, well, it’s one technique or the other or the other. They don’t understand that sometimes you have to actually combine techniques, right? Because you may actually come up to a certain, let’s say, categories first. And then you can put things within categories in a certain order, right? And then you can merge them and it’s set. So prioritization is key. So you can never come to your backlog item. A parachuting. And second worst is the stuff that you parachute is not even in a work order that anybody recognizes, right? Because you may be refining something that has very low value. Why are we doing this right now when we have a bunch of other stuff, right? So it’s a great point, you know, that that’s something that also has to be considered?

Gereon
Yeah. And so before you were asking, what people should do or shouldn’t do, and I’m, I’m somewhat neutral to that, as I said before, right, I want to make sure that it actually happens and that the product owner comes in having orientation, knowing what you want, which direction to go into. But one thing and for all of you guys out there, I’m I came from up from the scrum master side, right? So that’s always on my mind. And that’s where I have the most experience. And even though this is an event that’s centered on the product owner, I think, well the Scrum is, it’s really important to not just lean back and get a cup of coffee, but to actually facilitate this stuff. And when I say facilitate what I actually mean is play the Secretary, right? So if we are doing refinement, and I’m the scrum master on the team, I’m not going to relax and say, Okay, that’s her problem, the product owners problem, what I’m going to do is, let’s say I’m going to open the Azure DevOps, I’m going to open the JIRA, and I’ll be the person typing, because thinking through all the options, product ownership is really hard job, right? You have to balance all the stakeholder demands. And prioritization, as we just discussed is really difficult. And so the last thing she needs as a product owner is to be typing at the same time, right? And dealing with Azure, DevOps or JIRA. So I’m going to play the Secretary and nobody has to ask me for it to support the product owner. So the whole event can go down smoothly, right. And that’s, of course, aside from being the scrum master in you know, making sure we’re actually getting somewhere and making sure we don’t break the time box. But playing the secretary right in it doesn’t matter, that I’m the enterprise Agile coach. Now, if I’m in a team, I’m going to play the secretary because that’s what the team needs at the moment. Yep.

“Q”
And actually, I’m a bit more procedural than you are. But you see, I had scrum master that honestly fell asleep during reporting. It’s really boring for the scrum master to know unless you are a technical guy that used to be a developer or something right, but for the most part is very boring. Now, I had teams I had that team actually recently, they spent 56 minutes discussing a product backlog item ran out of time, they came back, this was on a Thursday or Monday, they come back they spent close to an hour. I mean, it was seconds, I was actually timing this discussing the same backlog item and said a we should have to discuss this. So I the meeting ended I called the scrum master and the product owner and I said, Guys, we need to talk right up. So he said, Listen, you guys been at this thing for two hours. Don’t you think? That this item wasn’t quite ready to He discussed. I just have a feeling that somehow this wasn’t ready for discussion, right? So they said, Well, yeah, cue I noticed that but what we do, right. So again, I’m more procedural. So my suggestion for them, which actually turned out to work really well. He said, here’s what we’re gonna do. Okay. When I call this again, let’s bring this refinery because we’re going nowhere, they’re at risk of having nothing refined for the next branch, right? So I called them I said, here’s what I’m going to do. So brought everybody in the room, five minute time box to discuss the item. Right? And obviously, they already knew the item quite a bit by that right. But let’s assume that we gave time to people to read about the item itself. That’s why I don’t like the parachuting, right. So five minute discussion. Okay. Scrum Master is in there that okay, stop five minutes. Guys. Is it okay can can we can can we figure out how big this is? And etc, right? If use point or not yet, can you join other fibers? Okay, cool. Not a five scrum master Rob? Bank. Guys. What about now? Oh, we still need to discuss it. I said, okay, cool. You know what this tells me? This thing goes back in a backlog. Okay. Because either has to be split something has to happen with their right. So we did this 10 minute bang, move down. Right? brought another item which they already had some knowledge about it. They discussed a little bit. Five minutes. Oh, yeah, we’re good. Let’s estimate being Scrum Master said okay. Let me let me pull the definition of ready, right, that checklist that helps us not to be in trouble, right. Then tang, tang, tang, tang, tang. Okay, we met the definition already cool. Another item, right. So to make a long story short, just by doing two time boxes, estimation and check, we’re spending at most 1213 minutes per item right at most. We went on that meeting from one item in two hours to five items in one hour. And after a couple of weeks there were averaging four to six product backlog items per hour. And I don’t need to tell you how much faster the plenty went. I mean, there’s no question about it. So not being too procedural. Obviously, this may not work for all the teams you know, and things sell don’t work for everybody. But I think Scrum Master should be thinking about keeping the thing on on the proverbial rails, right? If the train starts to derail, you have to do something about it. I’m boxing is a good idea, right? A pre refinement for instance, you get the PIO and somebody of the team together for like half an hour, once a week. And they look just somebody from the team can say a this stuff, what are you trying to do in there and it was like, it’s just putting in things. And then you announced to the team, what items you’re going to bring, right? So eliminates the parachuting. And then the scrum master takes a very active role at keeping the thing in the rails, you do that? These guys, I think sometimes they had like six PBIS in one hour, which is pretty good, which is very, very good. But there are some Scrum Masters have to take an active role in making sure the thing doesn’t get off the rails and product owners have to take an active role to properly prepare for the event, actually track refinements not an event that practice, but has to prepare for that. So we can actually keep things going. Right?

Gereon
Yeah. And what we’re not saying is you should have a pre refinement as an additional practice or event or meeting, right? So it’s not about adding another layer. But if you think about the job of the product owner, which is of course very difficult, but this is her job, right to think about this stuff to gather information beforehand. Because if we’re talking about it in refinement, it’s probably pretty, pretty high up in the product backlog, right? How did it get there? Because she’s thought it was important, and the team should probably do it next. But if she has like zero idea about how complex it is, then how can she actually come to this conclusion, right? So she has to have had invested some energy into this beforehand, before it even touches the refinement, because it’s complete waste. And we’re always trying to eliminate waste. If the whole team, right, let’s say it’s a bigger team, it’s nine people, they all sitting there and they are just beginning to understand what the ticket is actually about. That’s wasteful. And that’s why people hate the refinement, because everybody’s sitting there maybe on a topic that they don’t even have anything to do with it. Nobody understands anything and they just, you know, start to get it from 0% Slowly, slowly accelerate. And we don’t want to start there. It should be at I don’t know 20% Whatever right and then you can quickly take it to 100% of refinement.

“Q”
Absolutely. And another reason And why the product owner should prepare things in advance, you know, which I call pre refinement. Right? Is a sometimes you have people outside of the team that have to come and participate, right? For instance, I had a client. We were doing their website, it was a mortgage, Home Loans, right. And you cannot put stuff on a website that legal didn’t go through every single word in the stuff, right? Because you’re getting through. And one of the things that we noticed is, we would send stuff to legal until months later, where’s the stuff? Right? Oh, it’s on the legal backlog? I said, Yeah, God forbid, you know, the cobwebs are dropping, like a mile deep, right? And so what did we do? I said, Okay, you know, what, we are gonna have one, two sessions for refinement. One is only team only stuff. And another one is when we need to bring people externally, right. And we we set up that external one for people to come, it was always same place, same time. And so this was before COVID was a physical location, right? So every sprint, there was one hour where people from legal would come. I cannot tell you how quickly we got rid of the backlog of cobwebs that they had in there, because they come in under spot, oh, change that word, you cannot use that word, you have to do this. And immediately people would go there and change it. So you know, refinement, it’s not only for the team, you may need to bring people from the outside may need to bring people from security, for instance, it may need to be people for compliance, you need to bring people from HR, in interpreting people from legal right. There are all these people that you have to think the team doesn’t always have all the expertise needed, right? And especially legal things, right? I mean, you’re not going to put an authority in each team, right? So just bring somebody to help, right? So I mean, we got rid of a massive dependence, right of external thing. We also add that to the definition of ready under team and say, we have nothing pending, like copy, content, graphical stuff, imagery, pictures, legal bingo. And if we had those cases, we invite them to refinement, and nail the stuff right there. So the number of dependencies we had went from up here to way down there. So that’s what I call procedural, you have to think ahead and plan what’s the best way to facilitate flow through the system, right?

Gereon
Yeah, and it’s really found that because sometimes people will say, okay, but if we invest so much time in that, that’s where the actual work happens. And then during the sprint, we just, you know, check everything off and just finish it. And, yeah, that’s how. And this is why the teams can execute so fast during the sprint, because the staff has been, you know, it’s ready to roll. And you can actually just execute on that. And that doesn’t mean that it’s going to be done in five minutes. Right? But why would you want to inflict that pain upon yourself to start working on something that you have never thought about? Where you haven’t gotten the inputs you need and just, you know, almost guarantee that you will fail? Why would we want to do that we want to, it’s supposed to be ready, right? Ready for sprint? And then you want to start running and not you know, start tying your shoes after the starting pistol has already fired. Right? That nobody would do that. Imagine.

“Q”
Imagine in our case, we have this dependency problem, right? Imagine, we didn’t ask the the attorney to come to refinements, so Okay, well, we’re gonna wait until the spring. So we start to working. Okay, e g, I need to call Legal. You call Legal? Right? I can’t make it. So the end of the sprint, or the legal person ever showed up, so we go to sprint review. We didn’t do it. Why didn’t you do it? Or because the legal person didn’t show up? Well, didn’t you? Why didn’t you talk to them earlier? Right? And is that uncomfortable? Question is like, why don’t you think about?

Gereon
Yeah, and can I add something to that if you’re the legal person? Because I sometimes am the legal person. Nothing takes me off more than people say, Oh, well, we didn’t get an answer. Yeah, you dumb not because you asked like two days before the end of the sprint, when you should have asked ahead of time, right. And this is you’re really breaking a lot of porcelain by acting like that, because it you kind of make it look like the legal department isn’t reacting and they might be slow. They might be fast, but it’s actually your job to go to them ahead of time. Right? We can always work with interrupt buffers, but this is really not a good way to work with your colleagues and you know, to put them on the spot like that you it’s actually on you to communicate early and to get the information that you need from them.

“Q”
Absolutely. So few things that we we can derive from this conversation, right? One is product owners, you have to do your homework, call it pre refinement in the absence of a better name, before you go there may do this alone may need to do some help, right. But it’s usually very quick is just eight. This is what I have to do, right? The second one is a team, this is the list of stuff I’m bringing into refinement, okay, check it out before the event and all that stuff. So we don’t parachute stuff on. Oh, what, what, what, right? And third one is, is Scrum Masters. You know, what, you have a role to play in this thing, you know, please goes leaping on other another time. of year, right? I mean, somebody has to keep the thing on the rails, right? And number four is remember that you may need to invite people from outside of the team. So you don’t even create a dependency, you just kill the stuff right there. Right? Instead of bringing into the sprint, and then you have a dependency, surprise, surprise, we didn’t finish it, right. So those those four things, if you do that, your planning is going to be much smoother. And Garryowen and I will talk about planning in a future occasion, right. But think about all the things that you can do to make refinements more efficient. And I would say one thing we didn’t talk, it’s very dear to me is think about splitting the big stuff into smaller things, of course, because big stuff has a lot of surprises, right? Carry on.

Gereon
Yeah, absolutely. And I think we should talk about this another time, because there’s a lot to unpack, unpack there. Because, you know, how are you going to achieve flow if you’re just you know, taking one big chunk into the sprint, but I think you missed the most important point. And that is, please, please, please have refinements. If you don’t have refinements, you’re just invading, inviting pain upon yourself. And you’re just gonna be in for a very rough sprint, you’re going to be stumbling, you’re gonna be having painful sprint plantings. So people please do your refinements they’re there for a purpose. If they were a waste of time, we would have kicked them out of Scrum. Please do them and your life is going to be much easier.

“Q”
Yeah. And if you like being the rest of the team probably doesn’t be very carefully. There’s not everybody likes me. So I think that’s it for episode three. Again, I’m Q here in Dallas. And I always give the last word for my friend Gereon

Gereon
on cue likes to put me on the spot at the very last moment. So thank you guys for joining us again. We’re signing out from Dallas, Texas and Berlin, Germany. And hope to have you on the next episode. So download the episode four from wherever you you. Follow our podcast, this might be Spotify that might might be a cast. This might be Apple podcasts. This might be YouTube. Find us wherever you like to consume the content and we’ll hope to see you next time. Bye.