SCRUM Refresher: The 3:5:3 Framework

Speaker A: Foreign. Welcome back to class, my friends. We're moving into the topic Scrum. Not exactly Scrum. You know, for the longest time I got certified as a csm and if you asked me the difference between Agile and Scrum, I couldn't explain it to save myself. So let's delineate fact from fiction. Agile is a mindset that you can use to pivot to the ever changing world around you. That is the definition I gave you prior. But when we talk about Scrum, you got to understand that Scrum is a framework I'm going to read directly from the Scrum Guide. If you haven't downloaded it, go to scrumguides.org it was created by two gentlemen, Ken Schwaber and Jeff Sutherland. And together they worked on some information from a different source to put the idea together. Okay. And it just says, Scrum is a lightweight framework that helps people, teams and organizations generate value. Lightweight framework. Very, very simple. Very, very simple to look at and to follow, but to practice it could be the challenge. Right? It says it helps people, teams and organizations generate value through adaptive solutions for complex problems. In a nutshell, Scrum requires a Scrum Master to foster an environment. Now, what is a Scrum Master? More like a coach. Someone who is a facilitator. Someone who understands the rules of the game of Scrum and can coach and guide others. Right. It says, in a nutshell, Scrum requires a Scrum Master to foster an environment where a product owner orders the work for a complex problem into a product backlog. Now, what do we mean by a complex problem? When we think about complexity, we think about two dimensions, we think about a requirements dimension, and we can think about a technical dimension. Let me show you really quick. So Scrum is really good when you have, uh, requirements, high requirements, uncertainty, right? And high technical uncertainty. So somewhere around here, right, this region, Scrum works great here. When uncertainty is low, it means that we're more certain. And it's not that we can't use Scrum in those environments, we could. But Scrum is really well suited for uncertain environments in terms of the requirements uncertainty and the technical uncertainty. Right? So it says a product owner orders the work for a complex problem into a product backlog. Think about a backlog as a list of things. Number two, the Scrum team turns a selection of the work into an increment of value during a sprint. Number three, the Scrum team and its stakeholders inspect the results and adjust for the next sprint. That's it. Simple. Now, I'm going to help you better Understand what exactly this is about. Okay, so let's use an example of a family that is hungry. They want to eat a meal. Uh, they just come back from a crazy trip, like a trip I recently took, which was 18 hours, and they're famished, they want food and they got certain dietary requirements. Everyone in the family, let's say family of five, and they all want different things. So I'm going to use that to illustrate Scrum for you in a more pragmatic way instead of going over definitions and definitions, because I know you've gone over definitions and definitions in so many other trainings. So let's use a very, very simple illustration. So here we are, uh, we have a family, right? They are not very happy because they are hungry. They are hungry, maybe even hangry. Okay? They want food. So they've got all of these requirements, they got all these post it notes, these sticky notes, right, of things that they want. They're so hungry. We are, uh, hungry. Okay, we're going to put all the things they want. So you got 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 and 12. We got 12 different requests, 12 different requirements that they want. These requirements and requests, we'll call them customer requests. They are in what we call a product backlog. Okay. Now the product backlog is a living document, It's a living artifact. It doesn't have to stop and then, oh, you can't add anything else. No, it could actually live and we could add things to it. Right? So imagine the family of five. These are the people, we would call them the stakeholders or the customer. Right, the customer. If the customer decides they want something else at any point in time in this process, they can ask for it. So they add stuff to the product backlog. And now enter. The team. We're going to use a different configuration for our team members. And let's say, you know, in the world of Scrum, we say you cannot have more than 10 team members. So just imagine that we got, we got these interesting looking team members. Enter the team. Okay, so just imagine that, uh, we got all these people. We cannot have more than 10. Keep that in mind. Okay, so with a product backlog created, we're going to give one person on what we call the Scrum team the responsibility of being a product owner. And the product owner owns the product backlog. That means they understand the product backlog backwards and forwards. So we're going to make our, uh, product owner this, this guy right here and he's wearing a tie and looking all Cool, right? So that's going to be our product owner. The product owner is the ideas consolidated. They understand the value of what is in this backlog. And in the world of Scrum, we do things in iterations known as sprints. So it's okay to have a backlog, but when we're going to begin work, we have to work in a sprint. And the sprint could be four weeks or less. So I want you to think about the team. They are about to get into the world of, uh, the Sprint, and this green frame is the sprint bubble. Now you might wonder, why am I making the sprint so visible? Well, I want you to understand that in the world of Scrum, we have these meetings which we call events, okay? And in the world of Scrum, there are five of the events. But of these five events, one of them is a container for the other four and that one is the sprint. So this is your sprint right here. Your sprint is a container. It's a container for everything that's about to go down. Okay? So to begin working in the Sprint, the very first thing that we're going to do is known as Sprint planning. This is where the team takes a, ah, look at this product backlog. They size the items in the backlog however they wish to. Some teams in the world of Agile use what we call story point sizing. Some use T shirt sizing. They say, that's a big shirt, that's a small shirt. Some use animal sizing. That's a dinosaur, that's an elephant, that's an ant. They use these comparisons to come up with relative sizing so that stuff should happen. And then we also go through an understanding, with the help of the product owner, of some sort of refinement to better break down the items, understand them and target what is going to be done in the sprint. So here we have the Sprint. Okay, we're going to target what is going to be done in the Sprint by having our first event. And for the events, I'm going to use a, uh, kind of cloud formation to let you know this is an event and this is called Sprint planning. Sprint planning, Okay. The sprint planning event is where we ask the question, what can we do in our product backlog within the Sprint? And in order to do that, we need to see our Sprint backlog as a subset of our product backlog. So when we take a look at our Sprint backlog, assuming the items that make their way into the Sprint backlog, because this is going to end up being called a Sprint backlog. Okay, Sprint backlog It's a subset of our, uh, product backlog. So let's say we take a look at this and we say, okay, there are three items that we can do here. We can do item one. We can do item. Item two is too big. We need to break that down a little bit more. Item, uh, six is going to be part of our first course meal, and then maybe item eight. And the team agrees that, yeah, these are the three things we can do in this sprint bubble. Right? Because, uh, in this endeavor, we're going to have many sprints over time. Like in the real world, you can have 5, 6, 7, 8, 9, 10 sprints. You could just keep sprinting for years on end as a team, adding value. So at the end of sprint planning, we have our, uh, sprint backlog. And our sprint backlog, by the time we get here, we understand our sprint goal. Maybe our sprint goal is going to be our, uh, appetizers. So we got these three items, which are appetizers, and then we begin to work the appetizers. At this point, at the end of sprint planning, the team has their sprint backlog. They've broken this down into enough information to understand, can this be done in the sprint? Who's going to do this? Who's going to do that? They pull the items to themselves. You see, it's a different mindset. Unlike the world of traditional, where it says, you are going to do this, Phil, that's your job. Mary, that's your no. In this world. In this world, we have a pull mechanism where the team says, okay, I can work on that. I can work on that. So they divide and conquer. It's a team sport. So when they've decided who's going to do what, the next thing that happens is, of course, we begin to work. So remember, we are already in the sprint. And remember, the sprint is four weeks or less, which means it could be one week, it could be some days. Okay? So when you think about Scrum, you got to think about it as a framework. You're not bound to do things in two weeks. You could do it in one week. Your sprints could be even in days. You decide, okay, something that happens in the world of Scrum is every day as the team works. You know, it said business people and developers should work together daily, right? So in the world of Scrum, we work together daily. And what happens daily is what we refer to as a, uh, daily scrum. Daily Scrum. What is a daily scrum? Well, every 24 hours, right? The team product owner, Scrum, Master and developers, they meet to sync up and it's really a meeting that is for the developers to sync up. So the product owner and the Scrum Master could be in attendance. In the early stages of a team that is a young team just working together for the first time. And I, I don't mean young in age, I mean young in them being together. You might have the Scrum Master actually facilitate it. And the Scrum Master will ask the three questions, what did you do yesterday? Person X to move us towards our sprint goal of having all the appetizers done? What are you going to do today to move us towards our sprint goal of getting the appetizers done? And are there any impediments, obstacles or blockers in your way? You get it? The three questions, what did you do yesterday to move us towards the goal? What are you going to do today to move us towards the goal and are there any impediments? You could also ask the question, what have you done since our last meeting to move us towards the goal? Let's say this is, uh, a Friday, right? You're not going to be at work tomorrow, maybe. So the questions, you pose them in an intelligent way, but it's generally those three, what have you done since our last meeting yesterday? What are you going to do today to move us towards the goal? And are there any impediments in your way? And we go around the room, everyone answers these questions, who is a developer? Now, if the product owner is doubling as a developer and the Scrum Master is doubling as a developer, then it would make sense for them to answer these questions as well. The more mature a team gets, the less you need to ask them the questions because everyone knows the questions. So they generally just go round robin round the room. And this is not a status meeting. Very important you remember this. This is a sync up meeting. The intent is to sync up, to understand where the work is and to know if the ball is going to be passed to you and you're going to run with it and you're going to pass it to someone else. So it's a sync up meeting for the developers. Way back in time, early day, agile, the joke was there are pigs and chickens in the world of Scrum. The pigs and the chickens. The philosophy is that the chickens, they make a donation, but the pigs do all the work. Pigs, total sacrifice. It comes from the joke of the pig and the chicken. They're going down the road, they see a diner and the, the chicken says, hey, let's go and have Some breakfast and the pig says no. For you it's just a donation, for me it's the ultimate sacrifice. I'm going in there. So the, the funny idea is that the pigs do all the work. So only the pig stalk the chickens who are like management or the non workers, the non developers, they don't say anything but it's a joke and I think people got a little bit sensitive to that joke pigs. So anyway, long story short, only the developers speak. Even if you have senior management in attendance, they ain't going to say nothing, they're just going to listen. And in fact we don't encourage them to join except there's a founded reason for them to be in attendance. And if the team is given a heads up and they agree, but it's generally a sync up meeting. Another way you can have these Daily Scrums is you can do what we call walk the board. And walk the board means we have a Kanban board, either physical or electronic. And the team, what the team is doing is they're starting off from what is closest to being done on that Kanban board. You know what a Kanban board is? It has to do, doing and done for us to track the work visually and whatever is closest to being done and we can have sub states and so on, but whatever is closest to being done, the team members will talk about what is preventing this from getting to done. And we can walk the board as well. That's another way that we can work these daily Scrums. So it doesn't have to be the three questions, but the Daily Scrum is definitely a feature in the world of Agile. You hear people referring to it as a daily standup, you know, and that's pretty much what it is, Daily Scrum. Okay? Now in addition to the Daily Scrum, there's one other event that could happen somewhere in the middle of the sprint, okay? And this event is not a mandatory event, it's not non mandatory, okay? And the event that I'm talking about is where the product owner works with the developers Scrum Master and they take a look at the backlog and they ask the question what should we do in the next Sprint? What in this backlog needs to be broken down because in the backlog you have all sorts of items. Not every item is ready to be worked on. Some of them are so big. So in the world of Scrum we use, you know, a lot of people. It's not, doesn't have to be Scrum. It's not in the Scrum guide But remember, Scrum is a framework, so we bring in some other ideas. And one of the ideas we bring in is this thing called the Invest acronym, right, Independent. We say that our items, uh, in there, in our product backlog, in order for us to say they are ready, they meet the dor, right. Definition of ready, independent, negotiable. They shouldn't be hardcore requirements, they should be valuable or vertical, which means they cut through enough functionality for it to make sense. You know, like when you're serving a cake, how do you cut your cake to serve? Do you cut it horizontally or do you cut it vertically? You cut it vertically. Why is that? Because you want it to go through the layers of functionality, the layers of value, so that it makes sense. So we have valuable or vertical estimable. We should be able to estimate it. It should be small enough to fit within a sprint and it should be testable. See, so when we talk about the world of Scrum and uh, items in the backlog, we want them to meet the definition of ready. And the bubble, the non mandatory event that we use to describe that is just called backlog refinement. So backlog refinement. Is m this non mandatory event. So let's put that cloud around this so that you know that this is an event. This is non mandatory, which means you will not find explicit mention of this as an event in the Scrum um, guide, but it is recognized as an event by the PMI in the Agile Practice Guide. And many companies do this. It will be foolish not to do this. Now, it's not mandatory in the Scrum guide. Ken and Jeff, they make it clear that as a product owner you better have that down. You bet. You better be doing some refinement. Now it doesn't have to be an event, but you sure better be doing it because what happens when you get to the next sprint and you have these big old pieces of work in there, you know what I'm saying? So you got to make sure that this meets the definition of ready before you get to the next sprint. You, you want to have items that meet the definition of ready. Don't get to your sprint planning and then begin to do all this work because you very well could have too many things to break down. You got to decompose, break down the big boulders you see. So in this world we have different terminologies we use. And I'll just give you a mnemonic, the mnemonic when you're talking about your backlog items, what is in here? We have Phil Eats fries seldomly on Tuesdays or sometimes I would hate to keep eating fries. Maybe one day I'll stop sooner than later. Right? So Phil eats fries seldomly on Tuesdays. What on earth are you saying, Phil? What does this mean? Okay, this helps you understand the hierarchy of things. Inside this, we have the product, the product level, we break that down, we've got the epic level, break those down into features. Features could be broken down into stories, and stories broken down into tasks. And these are all, like I said, in economies of scale. So you've got the product level, you've got the epics, You got the features, These are broken down into stories, and these into tasks. Okay? And just remember, the way stories are written is in the. As A, I want so that format, right? This is the format for your story, your stories, right? And the stories, I just say we use the RGB approach row as a, what is the row? I want the goal. And B, for benefits. So that benefit, role goal, benefit. As A, I would like so that. So I've, um, unpacked a lot of things here so that you understand the philosophies involved in backlog refinement. Two things to think about. We want to get to the definition of ready, right? We want to ensure that we break down the big masses of epics into features. And the features are groups, user stories that are grouped together for release. It makes sense to group everything regarding login, group them together, everything regarding purchasing in a system, put them together. So features, they group the stories together for release. Tasks are the actual work. And when you think about it, everything under the story level, the task level, this is not value to the customer because this is just a task. The actual value are, uh, the story, the features, the epic, the product levels above. So tasks, even though they're very helpful to the team, you got to understand that the itty bitty tasks of hours, and we don't get into all that in the world of Scrum from a customer perspective. Unlike traditional, where we want to see the itty bitty tasks and then we hold the team to the fire regarding those tasks, we don't do that here. It's a different philosophy. Okay, so my friends, over the past number of minutes I've been breaking down the concept of backlog refinement and some of the mindedness of that you should use to approach this. Okay, all right, so that's the definition of ready. I'll just tell you there are some zealots in the industry who do not like the definition already. They're like, well, it's just like a gate. And um, we don't like gates in Agile. Okay, well, don't tell that to the pmi, because backlog refinement is talked about in the Agile Practice Guide. There's nothing wrong in it. Okay? And then don't forget the product backlog items, the pbis. Your PBIS are epics, features, stories, tasks, roll up to the product level. But let's get rid of this just to declutter the board because there's so much stuff on it. So if you need that, you can go back and re, uh, watch. Okay. All right, so now that we've talked about backlog refinement, the optional non mandatory step after we're done with our, uh, Sprint, we are going to get something that we call a potentially shippable increment. Okay. We're going to get some measure of functionality. Okay. And in this case this is figurative, right? Like, I've used the radio for the longest time in some of our previous, uh, episodes, but for this one, we're actually going to look at this as a different dish. Remember, in our example, we're not necessarily building something technical, but we're going to feed these hungry people, right? So we got a plate, we got the leg of chicken, or chicken nuggets, whatever the appetizer is, but we got, we got some food going on here, right? We got, we got food going on. In my very pedestrian representation of the food, I'm doing my best. Don't judge me. Those of you artists who are laughing, uh, don't judge me. All right, so that's our appetizer. In this world of scrum, we call this a potentially. Shippable. Increment. So a, um, psi, potentially shippable increment. And what we mean by potentially shippable is we could ship, but we don't have to if it's not featured enough. So what happens after this potentially shippable increment has been created? This increment? Well, we got to get this in front of the customer, right? So there's an event that's going to take place and the next event, which comes as a result of us getting this psi. Remember, the team is working together. It's a team sport. The team is doing different things, but it's all going to be integrated together into a psi. When we get this psi, the next event that's going to happen, I should actually make it come down a little bit. The next event that's going to happen is called a Sprint. Review. And in the Sprint review, the team shows off, uh, what they've done. They demo it. You might hear people refer to it as a demo, but it's not just a demo. It's more than just, hey, see what we did? Yay, us. Uh, no, it's not that. It's, hey, here's what we created. What do you think? Any feedback? Is there something that you feel we could add to this? Is there something that you think could enhance the value? So the Sprint review is a working meeting. It's not just a mere demo. Yes. We're going to demonstrate what we did. But remember, this is a meeting where we are syncing up with the customers. Those are, uh, hungry customers there, remember? So we have those same characters who are here. And that smell of that food, the aroma, it hits them. They're all happy. They're like, oh, my goodness. I never thought I'd see the day when this appetizer was going to hit the table. We're ready. Let's go. Let's do it. So at the Sprint review, they might come up with some additional ideas and additional flavorings and additional sources that, ah, they think, you know, what, you know, you could add this. Oh, in the next Sprint, when we were having a main course, why don't you do this? Or, you know, I just thought for the dessert, you know, we actually didn't put anything like ice cream. Well, we want to add this to the backlog. So maybe at the end of the Sprint review, the bright idea, number 13, add some ice cream to the backlog, and that happened. So I want you to see this as not just, you know, a demo, but it's a. It's a working meeting. Okay? We, we taste what is what, what's there, and I mean, oh, lovely. Can you add a little bit more salt? Can you do this? Can you do that? The team takes notes and they decide to do whatever they're doing next. Okay? After the Sprint review and the team has an understanding of how well things went, we have a final meeting. And this final event, you got to remember, we call them events, is called a Sprint retrospective. And guess who's in the retrospective? These folks. All of them. All the team, they're here. Product owner, Scrum master, the developers, they're all here as well. Okay? In fact, some teams, when they're about to end the Sprint, the Sprint review will happen in the morning. In the afternoon, there's a Sprint retrospective. In the Sprint retrospective, remember, the team is reflecting how to do better. They adjust, you know, and they decide how they're going to adjust. So they very well could come up with some ideas, right? They could come up with some ideas. That's a light bulb. And the ideas can be acted upon immediately. Ideas, how can we improve? And you see the improvements, they're not going to be left on the back burner till, okay, I guess we'll do that. So many years from now. No, they decide, what are we going to do in the next sprint to get better? Or they could even say, what are we going to do right now? Oh, it's a mental adjustment. Why don't we do XYZ right now? Or uh, why don't we think this way right now as opposed to how we've been thinking before? So improvements in the retro, they could result in, they don't have to, but they could result in an item going into the product backlog and consequently in the next sprint, making their way into the Sprint backlog automatically for the next sprint for improvement. Okay, so we've talked about Scrum. It has a 3, 5, 3 configuration. 3 roles. Product owner, Scrum Master, and developers who do the work. The developers are the coders. In some projects it will be the engineers and some projects it could be the field service engineers. Some projects it could be the food technicians or other projects it could be the pharmacist, but it's the people doing the actual work. So we have the product owner, the Scrum Master and the developer. Then we have five events. The Sprint, which is a container for everything else. That's number one, Number two, Sprint planning. Number three, the daily Scrum, number four, the Sprint review, and number five, the Sprint retrospective. Next, we have three artifacts. Okay, this artifact, I probably should make it consistent for the sake of the illustration because we have a product backlog, a Sprint backlog, and a PSI potentially shippable increment. There you have it, my friends. That's how Scrum works. And remember, we have the non mandatory backlog refinement that happens in the middle of the sprint. Somewhere in the middle of the sprint. Okay, to get more information about this, you can go to scrumguides.org take a look and you'll have a very solid understanding of Scrum. And just bookmark, uh, the video, come back, watch it over and over again and you're going to be good to go. Okay? I hope this gave you clarity. Remember, this is knowledge. We got to practice, We've got to pragmatize the knowledge. And when you see the questions, it's going to make a whole lot more sense. Go to the praise on channel and look for the 500 question series. I have 500 questions for you to expand your understanding, expand your mind and get go. All right, thanks for joining me. I'll see you next time. We got one more domain after this, actually. We got a couple of things. We got a little bit of kanban, and then we go into the business domain and then we're done.