Scrum Fundamentals for Beginners | Agile Scrum Course

1. Promotional Video: Hey, guys, Welcome to the scrum course. My name is Marie Zero and I'm a scrum master, an agile, certified senior project manager. And in these scrum cores, I'm gonna cover all of the different concepts tools, tapes, rituals, artifacts that are part of scrum. So that you understand what it sees as a framework on how you can apply to your projects. So we're gonna card from the A to the set off scrum and all the key fundamentals to ensure you come out of the scores scrum certified. But more importantly, that you can start applying scrum in your project in your business, on delivering those results that you're after, I'm sure you're gonna learn our lock in the scores. And I look forward to seeing you on the next one. Cheers. Bye. 2. Introduction, Scrum Fundamentals and The Definition of Scrum: Hey guys, in the scrum course, I'm gonna teach you everything you need to know about scrum. These will allow you to become either a scrum team member, a scrum master, a product owner or just someone who is really, really passionate about scrum and can share that knowledge with your work colleagues and with other people to richer goals and to help the business drive value for the organization . We're also gonna cover scrum fundamentals in the scores which is essentially pretty watching the essence of scrum. You need to understand what's chronicle about before you start applying it. So of course, we'll start off with the definition of scrum. What it is, you know, what are its origins? What's involving scrum? How do you apply it? What are the rituals that are part off it or the practices, everything that's involved in you working and utilizing scrum in your business. And then we're also gonna talk about what makes it different and special versus other frameworks or versus other methodologies. And I'm gonna compare it especially directly with water ful project management and the traditional way in which projects are managed on. You're going to see Major Major differences between the way people normally manage projects and the way you manage them using scrum. And these of course, is part of what you need to learn and what you need to do to become a scrum master. Because one of your big worlds a scrum master, is educating others on what scrum he's how to use it, its power and its value. So we're also gonna talk about why scribe me so valuable and so important and why so many businesses and organisations love it and why there's such a big demand and such a big appetite for scrum and scrum Muster's all over the world across many different industries and pretty much across any type of project. Now the other thing we're gonna cover in this course is how it can help you reach your goals. House Crumb can get you closer to those goals and why it's a lot better than other ways and traditional ways off delivering projects and traditional ways off reaching your goals. So let's dive right into it. Okay? What a scrum, Right? One of the things we want to learn in this course is what it means, what it is and Basically what you need to keep your mind in the scrum is a framework to so problems on deliver value. That's it. In essence, that's what scrum is. It helps you result problems on believer value to your customers. But it's also an agile methodology. It's one of the many agile methodologies out there, but it's actually the most popular, agile methodology out there, and there's a reason for them. There's a reason why it's one of the or not one of the It's actually the most popular, agile methodology, and it has to do with the simplicity and the power off scrum. It's also an interrogative and time bugs approached. And this is key. By the way. This is key because if this part off the essence off scrum as a framework, which is that it's something that you build on and continuously iterated and improved in a time box fashion right on by time box inscribe we're gonna be talking about Sprint's will go over the concept a little bit later on, but basically I just want you to keep in mind this prince, he said. Time box, in which you're delivering something in agile and it's particularly inscribes a methodology Orissa framework. When we talk about springs, we want to talk about a time books that is generally of two weeks, although it can go upto four weeks. But most scrum teams will be using a two week spring period. You'll find differences out there between different time between different teams Working with Scrum because some of them will prefer will use a faster period of time like a one week sprint. Others will use a longer spring time box like a two week, three week up to four weeks. But generally I'd recommend that you use a two week sprint and that's what we call a time box approach, which means you're delivering something over a specific set time frame which in scrum we called sprints. Incremental delivery with continuous improvement is at the essence and at the core off scrum. And by that I mean that your continuously delivering and incrementally improving what you're delivering on my dad. You know what I'm trying to say? What? What I'm trying to convey here with this particular point is that you don't just go right in and deliver the and solution where you're delivering something is scrum you start with something simple? Well, we generally called the M V P or minimum viable product and then you build on top of that as you're incrementally on gradually delivering value to your customers, to your business, your stakeholders to the people that are working with you on the project and so forth. It's also customer centric and it focuses on value, delivering often on delivering quickly. These guys, he said, the essence and at the core off scrum in scrum. We don't want to be waiting a year to delivery something like you see in traditional project management, which generally is referred to US Waterfall Project Management in Waterfall project management, things are generally delivered in sequence and they take a longer period of time to deliver . There's key time frames, faces, milestones, hard time offs on that generally leads sometimes and a lot of times to longer time. Friends sometimes inefficiencies scientists, bureaucracy, sometimes unnecessary documentation, sometimes too much documentation. And that's exactly what Scrum doesn't dudes. Crom is pretty much the opposite to all of that is very customer centric. It's very value focused. It's also very quick, and it's also about delivering often interpretive Lee and gradually and the other really cool thing about scrum, he said. In scrum you are very adaptable. You're very flexible and you're very fast so you don't have to do everything at once. You don't have to have the whole solution from the get go, you can build on it, you can adapt and you could be very flexible with what you're delivering. And when I'm talking about adapting in scrum, we're gonna be covering this a little bit later on. But we're gonna be talking about retrospectives and retrospectives is think a little bit as a lessons learned session. But it's a very particular scrum ritual which allow us to continuously improve to reflect to adapt on what we're seeing. All what we're learning right there on the spot before we get started with the next time bucks which we already talked about, he's called What? Yep. That's right, guys, I heard you say it in your mind or think about it in your mind. It's called sprints. Yes, it's crime. We talk about Sprint's which is that time books in which we're delivering value to the customer and value in scrum. We call user stories which are basically requirements. And again, I'm gonna cover a lot of that in more detail later on. But I want you to start getting yourself familiarized with the terminology on everything that we used in Scrum as a process, right? So a couple of terms that I've already covered that we're gonna talk a lot later on in more detail. But I've already covered in this initial session on whatis crumb are Sprint's right? The time works in which we delivers value or use their stories, their requirements and the workers get gets done, which in its crime would call user stories right. And there's a reason why they're called user stories because it's essentially telling a story off what needs to be done and why we need to do that. Okay, and we'll talk about how that looks like later on. And then we also cover another key concept in scrum, which are retrospectives which are essentially lessons learned on how we reflect for improvement. So that's it, guys. That's what Scrum is all about. As you can see, In essence, scrum is just a different way off delivering projects a faster way of the living projects, and it allows you to so problems in the business and deliver value to your end users to your customers. Interrogative Lee gradually and in a time box approach that it is very, very simple. And I can tell you from experience that scrum works and thats Krum is amazing. It's really amazing when you see teams that have been working on something for so long on are struggling with the Lavery I take you are taking for ever to take, you know, to deliver or to come up with their solutions or to provide value for the business on Then guys, when you start working with scrum, I will start delivering quickly and delivering often. It makes such a huge difference and you see so much value for the business that you're just gonna continue to use these in your projects. And if you're working on new initiatives, it's something that the values goes to record the business. Gonna start recognizing the value on you're gonna see the difference on why it's such a popular framework and methodology in the current and Mother world to deliver projects 3. Welcome: Hey, guys, I just wanted to welcome you really shortly and briefly to these course and let you know that I'm Peter Help and that I'm sure that you will learn a lot of these. Of course. Make sure you look at the resources that are available to you. The different downloads, the templates, the freebies. And just make sure that you contact me if you have any questions or if anything comes up or if there's anything you think it can help with. And mainly I want to make sure that you have a great learning and educational experience and that I can help you start your journey with scrum so that you can start seeing difference that it will make your projects on how will help you reach your goals and objectives in the business or right guys. Make sure you take notes throughout the course and we'll be in touch again soon. Cheers by 4. Scrum vs Waterfall: the key differences between Scrum and Others & Scrum value: Okay, guys. So let's talk a little bit more about scrum versus waterfall the new way versus the traditional way off running projects, right? And they're just keep in mind that these two things are two very different things to do exactly the same thing to in both scenarios, we want to deliver projects in both scenarios were trying to achieve something. But the difference between them is the how right on. I want you to understand this because it's actually two very different ways of working. And this impacts not only how you work with your team but also how you deliver and what you deliver. All right, So let's focus a little bit on the left hand side and look at scrum quick delivery with a focus on value and its customer centric. So we already talked about this a bit before, which is we're trying to do things quickly, but with a focus on value and the customer. What is the contrast to that in the waterfall world, where, well, a waterfall like I mentioned before, we're trying to generally deliver things over a longer period of time, and there's a lot more focus on the business and the requirements than actually on the value and the end user. Right? So when you're working with waterfall and traditional project management, you know there's it starts off. Generally, everything starts off from some requirements. And then it's about being some goals that are mainly business goals, right? So generally you have to meet some set time frames and said budgets and so forth. Not that that's unimportant in scrum it is it's just not the main focus off what you're doing, all right. And we covered also that in scrum we deliver it narratively right gradually right. We build something and we improve on that. And then we build something better on top of that week. Create something even better and so forth. Right? And in waterfall it's actually sequential so wonderful. General, you have faces. You face a B, C, D and so forth. You start with planning, then you go to testing. Then you go to delivery. Then you go to global alive and closure Everything in sequential right in agile. It's not like that and it's crumb. When were actually working with things, we're actually doing everything continuously. So we continually continuously testing were continuously planning were continuously delivering. And that's also one of the major differences that scrum has versus Waterfall now in scrums . Cup scope is actually variable and negotiable, so it's not, you know, hard set in stone. We don't actually want to shut down those conversations with stakeholders. If there's something that I think we should change, which is just what we should do differently or better in wonderful it kind of is generally scope is fixing waterfall and changes are frowned upon so people don't actually like or want you to make any changes in waterfall. And if you do, you probably have to go through a project variation process on, get signing from management, get go through tons of approvals and so forth because you've basically changed what you originally agreed to do or you're changing something in what you originally in the way you originally agreed you were going to do it and that, like I said, in Wonderful is not really something people want to see or they like. It's generally something that's frowned upon, and it's not really encourage at all and instead part of how you manage projects, wonderful bodies, crime. It's actually the opposite you know it's Grammy, actually. Welcome change. You actually constantly talk to your customers to urine users. Even within your team, you're constantly talking with them about how can we improve guys? How can we do things differently? What should we do differently on the next spring? Next time we do something and that's something that he said the core and that the essence of scrum is one of the reasons why I love it so much. So there's also continues reflection for improvement in scum. Right then, we talked about this before when I talked about the concept of retrospectives, right? So in retrospectives, basically, that's what we're doing. We're thinking about how we can do things better the next time around, right? And in waterfall. It's actually a big difference because in wonderful you do this. And generally it's called Lessons Learned or P I. R Post Implementation Review session and so forth, he held, has all of these. You know, it's a little bit more four mile, I guess, and it's always so generally done at the end of projects. So a lot of times you'll see wonderful projects, you know, after months of people working together they actually finish the project and then they sit down and reflect on you know, those lessons learned from that project so they can take that into account ing to the next project or other projects we're working on. But if you think about that, it's actually like you've lost months, right off things that you could have probably potentially already have improved or implemented Or, you know, just just taken into account in what you're doing right, which is again a huge difference with Crum and Scrum word constantly reflecting for improvement. We do it as part off. You know, the process on this part off us finishing a spring. The next step is actually reflecting on the sprint and going through that retrospective process, all right? And there's frequent testing, you know, Like I said in scrum, you don't just test at the end in Waterfall. It's actually done generally during a face on, you know, you say Okay, we finish planning. We're now moving to testing on the States for a few weeks. Then we sign off on plan on testing and then we move to delivery, right? It's krom. It's of a different in scrum. You actually want to test continuously as you're doing things and it's really something that is dynamic. It's evolving. And like anything else in scrum, it's actually continuously improving. You're actually continues with learning how to test better the next time or what you should do next time that you test something because you learned in your previous sprint, right? So that's something that is a beauty and it sells. Also report in the scrum and the other thing. That is also a key difference when you're comparing scrubbers. Wonderful these roles, right? So when you're talking about roles, you scrum generally, you know there's three big, big main roles which are, you know, the liver team, the scrum master and the product owner. We'll talk a little bit about each of those later on. But basically what I wanted to say here is that the traditional roles within from something zone kind of necessarily apply in the sense that it's not that you don't you know, have be ace or project managers or other. You know, other people working as part of the scrum team you do. It's just that doesn't mean that they necessarily have to play the role they have in New York chart. So, for example, a business analysts could actually be doing a bit off. Project management could actually be doing a bit of testing within the scrum t. And, you know, like wise, you know, someone that is normally in the roll off testing could be helping UI design or with a different thing in scrum, right? So we actually shift a little bit and Rose Blur. It's not such a hard line with rolls. People are actually collaboratively working together on solutions, and it's OK actually to step into someone else's role and help them out or work together with them into fearing something out. And it's actually encourage that you're constantly working with your team and it's it's kind of like more like it feels a little bit more like a closer unit is one of the things that is recommended. This scrum is also called location that people that are working to there are actually sitting together even if they report to different managers, even if they're from different parts of the business. Ideally, they should be ca located at a scrum team because then that can have those you know, constant conversations and one of the things is we're gonna talk about later on is you know , the daily scrum, which is basically also called the daily stand up in an agile and it's pretty much the same thing. It was one of those daily rituals that s part of Scrum, in which the team gets together and reflect some reviews. What their work on what they're working on and think that they can. You know, if there's anything blocking or affecting progress, how the team can result that and we'll talk a little bit more about, you know, the days crime later on. But basically, I just want you to keep in mind that, like I said it, you know, Rose Blur in scrum. And it's not such a hard line in wonderful. Well, there's very clearly defined roles, you know. People see it where they normally save those hard. You know, those those or chart lines are very, you know, very set they apply. And, you know, people actually rarely get into each other shoes or, you know, they're more, you know, if you're the architect well, you just focus on architecture if you're the test or were you just focus on testing and so forth. And like I said, that's actually the opposite in scrum. And all of these actually can be probably better summarized when we look at the diagram that I'm gonna show you next. So when people ask me to summarize scrum and what it is, I generally think of this picture because this picture to me, is the essence of scrum. It can't really think off anything that really conveys better. What scrum is then, what they're seeing at the bottom of your screen. This is what's promise. As you can see there you have five different solutions that have bean iterated and improved over time, and the customer is happy all the way. Why is the customer happy all the way? You know that smiley face that you see there? It's because he's actually getting a solution all the time. Every single time. You know what this is showing? You basically is Think about if you had someone that was trying to go from point A to point B, so just imagine that you had a customer, he said. They said to you, You know what I need to go from point A to Point B. That's it. That's my requirement, right? That's what I need. That's a problem I have. I need to solve this problem. I need to get from point A to point B in traditional project management would say, Oh, let's look at these requirement And let's think about the best solution we could build for these. What is the best thing we could deliver for this customer and how we can get him for point A to point B. What is the fastest way? How can we build something that is really robust, structured and that can deliver value for these customer? Right? And that is waterfall right water Felice Sequential. And what would happen in these traditional project management approaches? We say, Okay, let's build a car, then, that the car is probably the fastest being that's gonna get us from Point A to point B. The problem with building a car, though, is that it takes time, right? You don't build a car in a short period of time, it takes time to build a car, and while you're building it, you're not actually allowing the customer of the person to go from point A to Point B because you can't write the kind as you're seeing there on the screen at the top. You know they can't go from Point A to point B with just the wheel, and they can't do it with two wheels and they can't do it with two wheels and a chassis but without a steering wheel. Right? So there will in the fourth. You know, when they get to 1/4 stage where they have the whole card be able to get from point A to point B and it's gonna be pretty pretty quick and it's going to be really good for them. But by the time you actually reached that stage, a lot of time has gone by. A lot of time has gone by right and a lot of things could have changed as well. Well, scrum that's what Scrum talks about. A little bit of a different approach. And as you can see on the 1st 1 there in scrum, it's a skateboard, right? Doesn't do the job. Yeah, it does. It takes you from point A to point B. Easy as fast as a car or a bicycle or motorcycle or scooter. No, it isn't but we isn't it better to have something to go from Point A to point B. They're not having anything at all. That's exactly what Scrum is conveying here, guys. Thats exactly whats Crimea's alibi. You know, if it is a lot better for us, a cost over to have a working solution that you can use and then you can test and then you can actually look at and then provide feedback to the team about Oh yeah, I like the skateboard, but wouldn't be nice if I could get something would do this a little bit faster. And But by the way, while you're still being a little building, this scooter on the bicycle in the motorcycle in the car can still use a skateboard. So that allows you to solve the problem for your end user, but also allows him to start directly and continuously working with you collaboratively toward the end solution. You know the car, but all along the way, he's continuously working with you. He's giving you feedback, and it's actually being able to go from Point A to point B what he wanted to do all along. So that's why people really enjoys crime because it's such focus on, you know, week delivery, quick iterations, value and constantly direction with With the end user was with traditional part project management. Yeah, sure, you'll probably get to the end result. And I'm not saying by the way that traditional project management is bad. Waterfall is about it isn't, you know, don't get me wrong. There's some projects were waterfall is completely the best option and it has to do with the context of the environment. It has to do with the type of project it has to do with the time frame. The resource is with a little different things, right? Like if you think about a project and it just doesn't make sense to do it with Crumpton, why wouldn't you do it with scrum, right? You just can't fit everything toe a particular framework or particular methodologies. It doesn't work like that, But trust me when I say that scrum is generally applicable to the vast majority of projects and even if you didn't apply everything, that scrum he's is a framework assoc methodology You could steal probably a pry, a lot off scrum concepts, artifacts, you know, rituals and principles in what you're doing and get a lot off value for the business. All right, so I hope you're you know, you've enjoyed this diagram because every time I look at this, I just think it's so simple. Yet it's so powerful big because it conveys exactly what scrum ease exactly what wonderful is, and exactly what is. The difference is between them, you know, very simple diagram that anyone can understand. If you understand this diagram that you're seeing on screen, then you fully understand what scrum ease and you fully understand what water police are wonderful like we took before is a traditional project management approach, the way in which companies have been doing projects for ages for a very long time, and it's still the way in which a lot of projects are managed. And don't get me wrong. Like I said before, there's nothing wrong with that. There's nothing wrong with water full. I actually still use waterfall in some of the projects I work on. But scrum is a very different approach in which you can actually deliver a lot faster on a lot of value to the end user continuously interrogative Lee and gradually as you can see on your screen and there's a reason. Like I said before, why you're here, you're here because he probably realized that there's probably a different way of doing things. There's probably a better way of doing things that there's probably an alternative approach , that there's probably something which in which you can, that you can learn that you can take back to your business to help you reach those goals in your projects. Reach those you know, business goals, those team goals, those individual goes, and this is what scrum will allow you to do. Is crop will allow you to reach those goals a lot faster, and it will also allow you to continuously improve and to continuously. You know, crew create a collaborative environment in which your continuously delivering value to the business, and that's why I love it. It's crummy. So powerful guys, I've seen, you know, to give you a perfect example. Last year I was working on a project and I was handed over this project. They had gone through five different project managers three years, and they were still working the product. They hadn't delivered an in solution, and there were a little frustrations. You know, there were a lot of people that were stressed out. There were a lot of people that were happy because, you know, this and solution has never been delivered. And this had to do with, you know, traditional product management approaches off, trying to perfect things, trying to test things multiple times, you know, going through the sequential face one face to plan, test the labor clothes and so forth the traditional way in which you managed product the waterfall approach. And then when I worked with this team, we came up with a solution and proposed to management a three months, you know, time box, period, in which we were gonna go through different Sprint's right to achieve our goals. And we did. It was beautiful, you know, they loved it and they loved us. And we, you know, we were really happy with the end result, and management was super happy on. We were able to deliver the solution to the business really quickly, efficiently, and we were going us. We're going through our springs. We're doing a retrospective learning what we We could improve on delivering a better solution each time how many teams you work with can actually say that, you know, Like I said before, most teams will actually reflect for improvement at the end of the project on then it's too late because you can't do anything of that product. You'll you'll have to wait on the next one, right and the next one might be completely different. So all over you know, those lessons that I learned might not even apply. It's crime. What your learned. You're actually continuously applying to what you're doing on your continuously improving our learning from what you've done before so that you can, you know, deliver better value in what you're doing. And that's part of the beauty of Scrum. It's just super powerful. It's just an incredible way off managing projects, incredible way of working. And I also wanted to know what you're looking at. This thats Krum is based on empirical and promise. Also, empiricism, you know, in chronic is an empirical approach. I'm by empirical I mean that it comes from practice for what you're seeing, learning and doing, and that is also of the essence and at the heart of what scrum. He's as a framework all right, guys, I'm sure that after what we just talked about and what we just cover in these part of the course, you now have a clear I'm really good understanding about scrum what it is and how it differs from waterfall on traditional project management. 5. Scrum Origins | History of Scrum, the foundation of Scrum & where Scrum sits: alright guys. So let's talk now about the origins off scrum and this is mainly just for you to have a little bit of context and background off where's Karam comes from and how it has evolved over time. I always find it's really important for us to understand a little bit of history off what we're learning, because it just gives us a better understanding off where everything comes from, all right, and in the cases from, if we're gonna think about weight originally originally started, we gotta go back to the eighties where hero Taqa on E Koshiro first coined the term scrum when they were working on a product development article for the Harvard Business Review. So these two guys with which have, of course, a Japanese background coined the term into the context of product development. But the term really wasn't something they invented. Actually, they took the term from rugby as a sport on the reason they took the term from rugby's because he rubbed me. When you're talking about scrum, it's kind of like a playing the sport in which people, you know look down their heads together. You know the team, the rugby team looks down their head together, and then together they make a move and try to make progress and try to move forward into the field. So basically, they're all working together to move forward, to make progress. And in that position, or in that play within rugby. You know, when they're working with all their heart heads down and kind of look together, you know, type of like circle to move to move forward. The rugby team, you know, in that type of play, their role that the specific role they have destined really mattered there kind of all, you know, kind of equals kind of interchangeable and stuff like that. But anyway, the point they're being is that these two guys in the eighties took the term and used it into the context of product development because they found some similarities with what they were trying to convey in that Harvard Business Review article. But again, this is, you know, steal the early early day. So at that time, they didn't really, you know, put a framework er didn't actually developed further the concept of scram into methodology or anything like that. This was just them starting to use it concept into a context into the context off product development. So think about these guys like, you know, these two guys for mere like the granddads know the grandfather's off scrum as a methodology. But then in the night in the nineties came ganged waiver and Jeff Sutherland, who actually structured Scrum into a framework. So they took that concept even further on then, actually putting, ah, framework, economic ideology. And they put him high, would work. What are the concepts that principles the pillars and so forth? So they were actually working together collaboratively on, then actually set up what we know today as the scrum framework. And they presented these together in 95 in an event in the US which then became popular worldwide. And then they just started, you know, the information to start. It's spreading out from there, but this was back in 1990 talking about back in 1995 when they work collaboratively together and presented that per paper in the US But that was again kind of like a starting point for them because they continue to work together and then later on would go on Teoh, you know develop and start up things like a scrum alliance and scrum. The board and they also together call third in 2009 what is now known and famously known as the Scrum Guide, which is kind of like the Bible in scrum. Right, because these are these guys are kind of like the the Fathers of scrum on the scrum guide is just, you know, basically the framework of scrum put together into a guide that is available worldwide that you can find it. You can search, you can download and I'm gonna share it with your hearing the course. But don't worry too much about that. Of course you're pretty going on greed it on and see the original, I guess version off eight online But don't worry pretty much everything we're covering in the scores. He's based on the scrum guide. So like I said, this crime but it is pretty much the Bible off scrum. So of course, everything you're learning here in this in this course comes mainly from the scrum guide. And of course, it added a lot of more valuable information that will help you in practice. And when you put into practice scrum. So these two Americans, you know Shaver and Sutherland are currently recognized as the fathers and the founders of Scrum, and they still are very active in the global community and, you know, help out through different organizations. And, you know, they continue to spread knowledge and mentor people. And they're part of things like I mentioned before, like this Crime Alliance or Scrum scrubbed the board. And another thing, I think that it's really important to highlight about these two particular individuals is that they actually were part off the 12 people that release the agile manifesto in 2001. Now the agile manifesto and the release of the agile manifesto is a key advantage. The adult world worldwide. You know, these is kind of like the send, you know, this setting stone, the founding moment for for Agile as a consequence, the methodology When the agile manifesto was released on these two guys, the Fathers of Scrum were part of the 12 people that work on the agile manifesto and released it to the world in 2001 describing what agile is all about. And like I said, before off course, there are overlaps when you talk about agile and scrum because Crumb is an agile methodology. It's, you know, it's an agile way of doing things. So obviously they share things and have things in common because all of the different agile methodologies, in essence, are also agile, right? Like they come from the same thing for the same concept, right? So I guess is to put it into context. And I guess just to give you an analogy, think about you know, Toyota or think about Ford right there, cos right. And they're like a brand. But we think those brands, they have sub brands, right? Like they have particular versions of different cars. Right? So if you think about Ford, you have a Mustang, But you also have ah, you know, an explorer, right on an SUV. They're both different cars, right? But they're still forward, right? They're still part of Ford. And they're both part of the Ford brand, of course. Have four components. You know, they have Ford in their blood there Still four, in essence. And at the heart, they're just different types off cars, But they're still part of that Ford brand. The same applies to Toyota, right? when you think about Toyota High looks or you think about Toyota Corolla, right? Hi. Looks in until you are different cars, right? But they're still Toyota right there, still in the S. And so it's the same thing when you think about agile right? So this crumb think about the tour. 00 are you know, I think when you're thinking about Scrum, think about it. You know a son, right? Like a baby off agile right is part of the agile methodologies, you know, as an umbrella. But there are also they you know Scrum does have other brothers and sisters, right? And you have things like extreme program extreme programming. You know, you have scale, you have the as the M. All those are other agile methodologies like scrum on. They have differences, but they also have come. Finality is right because they're all part off agile. They're all under that big, agile umbrella. All right, so of course it's not really a surprise that the guys that found that scrum were also the found part of the founding fathers of agile as a methodology. And it's a big umbrella that covers different types of methodologies, right That's not really a surprise, guys. It's of course, that wasn't a coincidence, right? It's because these guys where part there, the fathers of from on there also part of the guys that found that agile right because he scram is an agile methodology. And the main thing I want you to take away from these He's that scrum off all the different agile methodologies that are out there. Scrum is the most popular, agile methodology on. The reason for that is because it's so simple. It's so easy to use it so easy to understand. It's just very logical and it's just very easy to put into practice so people love it. You know, that's what people love Scrum. That's why people have adds up, but in particular for the different, agile methodologies. People really love Scrum because of its simplicity on because it just delivers results right and don't get me wrong. All the other agile methodologies are also really good, but they're also a lot more complex. Some of them can be a little bit more bureaucratic. Some of them require more documentation than others. You know, some of them are very technical when you think about like extreme programming or, you know, you think about things like safe audio. You know that they're way more complex. There were way more structure. They have more structures around them and stuff like that, and that makes it off course, something that does not appeal toe. Everyone has hold. There's there's particular groups of people that want to work with those agile methodologies. And like I said before, don't get me wrong. They're all really good and really valuable. They're still agile methodologies. But if all those my favorite one and the one I like the mostly scrum and it's also the one that is most popular worldwide, almost widely recognized because of its simplicity and now you know where it comes from and how it's all interconnected. So just real quickly to go over what we just covered a moment ago when we were talking about the origins of scrum on house crime is part of agile. I just wanted to show you this quick picture off, how it all fits together and how it all seats were with each other so you can understand that relationship. So these, in this analogy that you're seeing that umbrella on screen basically like Like I said before, Agile is at the top of the umbrella, right? Fragile is kind of like the general high or arching methodology. And then underneath, agile, you have sub methodologies that are also part of agile. So they're all agile. Methodologies is just that they're a little bit different from each other. Kind of like the example I gave before. When you're talking about the Ford Mustang and the Ford Explorer, right, the Ford Mustang. He's a very different thing from the Ford Explorer. Yet they have commonalities here. They're still forward, right there, both four cars. Right, So this is the same. All of these methodologies here Scrum, Cambon, lean, extreme programming, the STM safe. They're all agile methodologies, but they all have subtle and sometimes big differences with one another. Yet they're all part of agile. Okay, so the ones on the left are what we call the lighter, agile approaches. And by that I mean there, you know, they're simple. They're easy to implement, Easy to understand. They have, you know, very, very many. I'm very, very minimalistic, approaching a lot of things and then under right, you have other agile frameworks and methodologies such as the STM on safe, that arm or extensive in their approach. So they're more structured, more robust in the sense that they might have a lot more processes in place, or different practices that make them a little bit more extensive than the ones on the left and their brothers on the left. There, they're all part of the same family called agile. And, by the way, in case you're wondering, what you're seeing on screen are not all of the all of the agile, agile methodologies that are out there officially that I don't think there is an official count off agile methodologies. But last time I checked, there's around 12 different, agile methodologies, and you can find them on if you go to agile cavey dot com, which is the website that I found it to share knowledge about agile scrum on all the different agile methodologies. You can read more about that there, but like I said before, you know there's not unofficial count anywhere. That is not one single person that have said Thies is all of the official agile methodologies in the world, you know, and there isn't for this is that this is evolving all the time, you know? So it's not something that study, so I wouldn't be surprised. Relieved, you know, down the track, more agile methodologies came about or, you know, in the future some of them were consolidated with some of the other ones. But don't worry too much about all the other agile methodologies and the numbers. I think that really is an important that key take away for for you here is to know that there's not just one single agile methodologies that they're several are out there, but that because we're in a scrum, cores were actually focusing on scrum and, like I said before the other thing, that it's really super important for you to take away. A swell is that off all the different agile methodologies that are out there? Scrum is the most popular worldwide, So a lot of times when people are talking about agile on, this is something that I come across quite often. Actually, they have no idea that there are actually multiple agile methodologies. They just think that there's only one and that scrum because they never even heard of the other ones and most of the time when people are talking to you about agile and they're talking about, we're gonna do sprains. We're going to use their stories, you know, we're gonna be working more agile. A lot of the times they're actually thinking about scrum. They don't even know on something. They're not even familiar with the term scrum because they're more familiar with the term agile and agile. You know, it's just the term that is just awarding itself. Kind of like explains itself. So because it has a meaning, right? Like when we think about scram. If you say to someone that has never even heard of Scrum they won't have, you won't mean anything to them, right? Because it's It's not an acronym, right? It's not a seen any off anything else. It's not something that is just has a specific definition in the dictionary or anything like that, right? It's a term that I could mention before it comes from the sport of rugby and that has now being adapted and putting toe a framework for delivering projects by these two guys. You know, back in the nineties, right? And you know, I'm talking about, of course, waiver and on Sutherland of The Fathers of Scrum. But like I said, the key point for you here Is that you? Of course, they are taking the scores to start working. What's Crumb are telling your different projects that you actually understand the differences on that? You can share knowledge about it, and somebody comes across and talk to you about, you know, agile. You can actually say to them what it means and explain to them that there's not just a single agile methodology, but they're spoke to pull out there. But you know, that's crime is actually the most popular one. And what are the advantages? And you can actually, you know, understand yourself that they all, of course, have commonalities because they're all agile methodologies. So I hope that these diagram with the umbrella helps a lot to under and the analogy again before, you know, with the brands of cars you know, when I was talking about two Yoda in and and Ford as just two particular examples by the same concept applies to all the other carbons. Of course, all of them have different models of cars, even though they are part of the same family or that they're part of the same brand. So I hope these you know, this diagram of the umbrella helps you understand that a little bit better. And I'm sure it's pretty clear, pretty self explanatory. Pretty straightforward. But if anything comes up, you know, if you're still have any doubts about the record questions around it, don't worry. Don't don't hesitate to ask. That's what I'm here for, guys, I'm here to help you. I'm here to walk you through the whole step in the full steps of these in a different process. And just for you to make, just to make sure that you actually fully understand what scrums all about and how it's different from from other methodologies and how you can put this into practice. That tit. And like I said, the beauty of it and the thing I love about scrums that is just so simple and easy to understand. And it's so simple and easy to implement and just delivers values so often because you're working Interpretive Lee and you're working to deliver things quickly and often. And I guess that last but not least, is that if you want to learn more about agile than definitely. I recommend that you go to you to me and search for the agile crash course, which is another course that I created specifically to cover agile as a methodology. And that course would walk you through all the different aspects of agile, including the agile manifesto, meets about agile and so forth. And even if you take that course like I mentioned before, you're gonna find that there are overlaps with Scrum because their whole so they're part of the same family, right? Like I said before, guys like you're seeing on screen, they're part of the same family. So of course you're gonna find commonalities between them. But the main thing here is that this course is focused primarily and 1,000,000 scrum and that if you wanted to learn more about Adua, definitely encourage cryptic another adult crash course, and that will allow you to see, you know, a little bit more off the different aspects of Angeles. Well, all right, guys, Ducks in by 6. Secret 1 of Scrum: secret number one is that it's Crumb is not on Lee for I t projects or for technology projects. Now this is a huge misconception around scrum and around agile, and a lot of people think that if you're not working on I T or technology Project that you can use from as a project management methodology and what I'm here to tell you is in this first secret scrum, he said. Actually, you can use from pretty much across any type of product on across any type of industry. Not only I t projects, you can apply scrum on procurement projects, marketing sales operations pretty much anything you can think off. And I'm not saying these just from theory or because I heard about it or because I read about it. I'm telling you this from practice because I've actually applied scrum across many different industries, different types of projects and in different regions and different countries. So I can talk about this was confidence and I can actually share from personal experience. That's Crumb has been a game changer in many different products that I have worked on across many different industries, so that's the first secret I wanted to share with you about scrum 7. Scrum Pillars and Scrum Principles: the solid foundation of Scrum as a culture: So let's go now over the scrum, Peeler's on in scrum. We basically have three peelers, transparency, inspection and adaptation on. They all work together on their or part of scrum as a framework and it's a mythology because they're at the core and essence off scrum and by transparency. I mean that everything that you're working on in scrum is basically for everyone that is working on the team and even for people that are outside of the team. So transparency is definitely one of those really big pillars in scrum because you'll see that when you're working with scrum, you know when we talk about our agile and of your scrum can been bored or your ideal kind of on board, you're going to see that you're basically putting out there in a physical or virtual way what you're working on and it's transparent and it's visible for everyone and everyone can easily see what we're think they're at right, because a lot of times when you're working on projects, that's one of the key things that people want to know about. You know, what's the status of things? Where are we at what's being delivered where what are we working on right now? What spending and stuff like that and in you know, it's crumb. That's really easy to see when you're looking at your scrum can been bored or your agile Cambon Borga. You know that you hear me, you'll hear me something. Say Scrum can be onboard and something say Idol camp on board because they're interchangeable. You know, some people call them Scrum camp on board. Some people call them agile, crumbling can been boards and some people just call them. Can been boards, right? Don't worry too much about that. They all mean the same thing is basically, you know when we talk about that later in the course and I'll show you a specific example. But it's basically a visual representation of what you're working on, and that goes to the core in essence of Scrum, in which you're being transparent with everyone in the organization, in the business about what you're working on, including your team, right? So there are no secrets in scrum. Everybody's across what everybody is doing and where we're at with things what's being done on what spending on what's a rate of execution and stuff like that which we'll cover later when we talk about things like, you know, the velocity, etcetera, right? And let's talk about the second pillar, right? Inspection, right? And inspection is basically you just reviewing what you're doing and how things are going and what's the variability versus what you projected. Right? And again, this goes back to looking at the scrum artefacts on by scrum artifacts. I'm talking about burned down charts I'm talking about, you know, your velocity chart on I'm talking about your scrum camp on board on these air, different artifacts are different, you know, I guess items with things crumb that allow you to track your progress and to see what is their variability versus what you had projected or what versus what you were meant to be doing overseas where you were meant to accomplish in a particular sprint, right? Because remember, guys that every time we're talking about scrum, we're talking about a very short delivery time frame, and it's not a time friend to deliver everything. It's a time for time for intimately for a particular set off work, right? And that particular set off work that we're delivering our user stories right and our user stories air just basically those kind of like those tasks that come from those requirements on what we're trying to deliver in our sprint and sprint like we talked before, he said. Said a particular timeframe for delivery that in scrum can be up to a month. But generally, you know, it's typically a two week time friend, all right, and that's what these pillar is all about, about as going through those different artifacts and just see where we're at and seeing what are the variances versus that and seeing you know what are the next steps, I guess. And also it allows us, which is also something that is very you know, the core, in essence of screaming, allows us to see what we need to improve on what we can do better the next time and so forth. And I guess the Firth of the Third and Final scrum pillar is adaptation, right? And basically what these Peeler is all about is that in scrum, we gotta remain flexible at all times, right? And unlike waterfall methodologies which we covered before you know the traditional way of the project in which you kind of try Continue doing following a very, I guess rigid approach in some aspect in agile were actually pretty flexible. Right on. We make adjustments continuously and it charitably as we're working through things. So if we're seeing that something is not working well, in agile, unlike in wonderful we're not gonna wait until the next project. We're gonna wait until the next sprint, right? So that could be the week after or two weeks after or through exist, er a month after. So it's a very short time print front time frame in which your adapting to that change adapting to, you know, something that wasn't working well and you need to do it better. And I think this is also super important. And this three pillar score combined are some of the reasons why Scrum You know, one of the many reasons was crime is so popular and so powerful because you're not, you know, just waiting until things break down to do things like here, you're you're being transparent. You're reviewing things constantly and you're adapting as you see fit and other teas as a team. And you know, the scrum team sees fit and this is like I said, you know, something that you were gonna find really valuable in practice because you're going to see that when you're talking on your junior your daily scrum with your team win, which you're basically, you know, meeting with them daily to discuss. Um, you know, why do you need the day before what you did that day and what men? If there's anything that you're planning on doing that, Danny first, anything that you need to remove us a roadblock, then you're going to see how that plays into practice to become such a powerful thing because you're constant interaction with your team on your adapting all the time to the different circumstances. And I love this because, you know, in the modern world, things are changing so fast. Everything's involving so fast. Sometimes we're working on things and we get thrown this curve balls or you know there's restructures in the business or things are changing. Or there's a new probably for managed from management and stuff like that, and that you know, you're working and I guess, the traditional way to match projects. It'll take you a longer time to react to that, and some things By the time you react to that, you know, you kind of missed the opportunity or it's just taken too long. What's crime? You're actually adapting, you know, in real time to things, and you're putting that into practice and making sure that helps you meet your goals, meter of their objectives and meet those key deliverables off your projects. Now let's talk about scrum principles and there's six scrum principles empirical process control, self organization, collaboration, value based prioritization, time boxing, an interrogative development. Now we've actually covered all of these things already or most of them already. So these, of course, it's not something new for you. It's just that I hadn't mentioned that, Actually, those are also scrum principles. But this is pretty cool, right, because you're already familiar with some of these or with all of these. But now I'm putting it formally for you here on screen as the six scrum principles that are part of Scrum as a pathology. All right, let's just go real quickly through each and every one of them. The thing I like about them is that they're very easy to understand that they're pretty self explanatory, but let's start with the 1st 1 right? Okay, So it critical process control and basically what this is saying to you for those that are I think most of you are familiar with in Paris it and purses Immuno empirical on an empirical approach on basically and and pretty cool approach is about learning from practice, you know, learning from experience, right. And that's what we do in scrum. You know, we're basically looking at things and we're actually learning from reality from practice. That's empirical process control. And you know, we talked before we were talking about our pillars Transparency Inspection adaptation thesis where it's actually strongly reflected in there in the principles of scrum in the empirical process Control self organization in, you know, in scrum by what I mean by that and what you know, what we mean by that is in the world of scrum is that teams organize themselves so they define what they're going to be working on. They define their priorities. So a scrum team doesn't have you know the manager coming to tell them you know how to do their day to day job. And given that I'm fund and telling me specifically what to focus on what to party ties and stuff like that really doesn't happen like that in scrum guys. And this is one of the key differences. Also inscribed verses. A lot of other ways of managing projects. I'm working on projects out there, and that's that. The teams here are self organizing, you know, they define what they're gonna be working on. They prioritize themselves directly off course they take into account, you know, with what the what what is a directly from what we call the proud owner and scrum right, which is basically either the client or the customer himself or a representative of the customer and, of course, driving what we should be focusing on based on what you know. There, either priorities for them as a customer are or that representatives representing the you know, the product onerous representative representing the customer than what he knows the costs are the key thing for the customer, right? But self organization is pretty much like I said, pretty self explanatory where we're saying that you know this crime team and everyone that is part off the, you know, working with crime, self organized, right collaboration. Yes, we already know that on, you know, Scrum as awarded itself coming from rugby, where we're talking about the team, looks down there, loves with their heads down to get it, to move forward in rugby. And it's the same concept, right? So in scrambles as a you know, it's a methodology to deliver projects off. Collaboration is huge. Your economic working really closely with everyone that is part off the scrum team and even other stakeholders that are not part of this Crumpton are gonna be, you know, constantly interacting with them and describe my surprise A really key role here because the scrum master through the different scrum re trolls facilitates that collaboration and ensure it is a really good thing with the team. There's really good communication with the team with the product owner and with the different stakeholders that are, you know, that are part of the project value based privatization, which is the fourth scrum principle is all about what's important for the customer, right? And what did I just say a little bit earlier? And what what we've talked about up until now, right? Hoole represents the customer in scrum. You got that right, guys Yeah, the product owner. Yeah, product owner. And I don't worry too much about these. You know, we'll talk a little bit more about the product owner later on either course, but yeah, you got that right. You have the person that defines what are the priorities for the costumer because he's either the customer himself for a representative of the costumer, is the product owner, right? And that you know the value base party take privatization comes from off all the things that we're working on. We want to focus on first, the things that deliver most value toward customer most value to a product owner because it's kind of like, you know, you're actually focus, focusing on what's really important for them on your delivering. Often you know, the agile way you know, delivering often delivery quickly. And that's what What's so beautiful about screaming White? So powerful, right? Because you're focusing on value right? The fifth Spieler that the fifth principle that we have here sorry is the time boxing right and time boxing is pretty much just covered by Sprint, right? And when we talked about the sprints, you know, in the time boxing, that's particular period of time in which we're gonna deliver. That is crumb. Most typically is two weeks, right. It can be up to up to four weeks, so it can be up to a month. And don't get me wrong. We talked about that agile and scrum reflect flexible, right? So you could increase that period of time. Or you could use it if you think it's gonna work best for your team. But I generally recommend to scrum teams to start with a two week time books two week sprint on. Then they can generate on that later on if required, if required. All right. And then the sixth and final principle were talked about he We're gonna talk about easy alternative development and a key point, I guess I wanted to mention here. I know it has a word development, which sounds very I t on, which sounds very, you know, I guess product focused. But one thing I did want to mention is that scrum, even though it was kind of originally the sign and, you know, it came from the concepts and focus on product development. Andi has a strong focus, and I guess it came from I guess the world, if you want you want to say so or think about that doesn't mean that scram is only applicable to products. It's also applicable to services on. It doesn't mean that scram is only applicable to technology or i t. It's actually applicable to pretty much any industry out there. And you know, this is not just something I'm making up, you know, if you want to research or Google it, feel free to researcher Google examples off scrum in marketing examples are, you know or scrum in, You know, health or whatever you know, and you're gonna find that there's there's different case studies and different people applying scrum agile and you know, an agile methodologies in very different industries. So I guess I just wanted to make sure that now they were covering the principles that's clear for you because also something that often comes up where people think that, you know, this is just applicable to i t. And product development, and the reality is not. I personally, myself have worked on many different projects in many different countries where I have applied these in, you know, operations projects, procurement projects, sales projects marketing projects. And you know that the essence that the same key concepts of Trump apply regardless of the industry. All right, an eternity of development is part of that alternative development is that you just don't focus on an end solution that takes forever to deliver. Alternative development is you deliver value often and quickly, and then you continue to improve on that and continue to improve on that until you get there to the end solution with all the bells and whistles if you give you if that's what what is your end goal? But it's kind of like you just continue, continue, continue alternatively and are often are delivering often and they're delivering value to your customers. And I guess I'll just put here on an example off what alternative development might look like in, Let's Say, marketing Right. So let's think about our marketing campaign right, and you're thinking about that. So you're gonna think about flyers and ads and then TV and radio on different You know, different channels, I guess, for your marketing campaign, right, so on. Alternative development and alternative approaches as a principle here would apply that, for example, you could say OK, I'm gonna start off initially with the TV ads. So you focus heavily in your first print on the TV ads and then release the TV ads and they say, OK, our second split is gonna be are the You know, the user stories are going to be part of our second spring are not gonna be focused more on the on the flyer. So all the word so you can deliver the flyers in your second spring on, Do you eat a right? Right. This a second iteration, right? It's a second sprint, and then you focus on radio right on the tip of your third sprint. And that's what that's what alternative development is all about is that you continue to build on and upon what you've already done without having to wait. You know, six months toe release that marketing campaign. You actually eat a relatively deliver value, right? Because people are seeing tangible things, whether it's a brother, whether it's a service that they can actually, you know, get value from. And that's what you know, what screaming is all about. It's about delivering value, and it's about believing that value often so that tip guys, we've covered the six scrum principles and just to wreak up that six scrum principles are empirical process control, self organization, collaboration, value based privatization time, boxing and eternity development. 8. Scrum Values and Scrum Resources: the essence of Scrum as a culture: in this lecture of the course, we're gonna cover scrum values on there's five scrum, Bali's commitment, courage, focus, openness on respect again all of them really easy to understand, really straightforward, really pretty much self explanatory. So what does this all of these different values? What do they mean? Actually, in the world of Scrum, what commitment is that? If you're trying to leave or something, you actually fully commit on the lever that on time and on budget and as planned? Right? And that's why in scrum, we have our different artifacts, right? And we talked about the different artifacts such as a burned down charred, the scrum can been bored and your velocity chart which allows you to see how your meeting, those commitments, how you're doing versus what you you know, are focusing on trying to deliver right and then courage. Courage is about trying to sometimes think outside the box trying to do things differently , crunches about, you know, having that energy and that strength to make those tough decisions when you need to make them. Sometimes you need to change, you know the order or take a different direction, or take a different path because it's not working as your expected. That's something that in scrum we learn through retrospectives, right? So I'll give you a perfect example of courage. Andi, this is something that happened to me not that long ago when we were working on when I was working on a project and I was actually using strumming that project. So we went through a couple of springs and then I noticed that we had reached a 3% completion rate off what we have predicted to complete right, and to put that into context. When I looked at the stats and I saw that we were were 3% completion rate, we should have been really at about a 50 60% completion rate on. I knew we were running out of time. We're getting close to the end of the year, and I sat down. Did the math look at you know, I looked at the previous sprints, looked at our velocity, which has been pretty much a rate of execution and then looked at where we were in terms of completion. And then I four forward projected what we would accomplish by the end of the year, right and at that time. Like I said, we were on Lee at a 3% completion rate. So when I did that exercise, I realized that if we continued at the same pace would hit the end of the year with less than 60% off completion off what we had we were trying to achieve. So obviously that was unacceptable and something needed to change. You know, the team and I would you know, we talked about it in a retrospective and thought about while we needed to do. And we thought we need to completely change the delivery strategy. We need to completely change the way you know, we're working on this, and basically what we did was because before we were getting kind of the people that were working on some key stakeholders to provide some information for us, and that was always taking alot longer than we had expected, anticipated on when they were providing the information, information wasn't really organized and it was less than we were expecting. So we said, You know, let's completely change the strategy. Let's let's take the data ourselves. Let's look at the debt ourselves. Let's put a plan in place let's propose it to the to the stakeholders. We'll work on that unless they tell us they want any changes. But we're actually doing the inverse instead of asking them to provide, you know, the organized data for us to work on. We did it the other way around. We provided the organized that off for them and said, OK, we looked at everything. These is how we're gonna be doing it. And this is how we're gonna be doing our springs is the work that we're gonna be doing an inch sprint. And we said to them, You know, we've kind of taken ownership of your data, but we want to let you know that it's not selling stone. If you want to make changes, we can make changes were flexible. We're adaptable. But that helped guys. And that was, you know, we had the courage to completely change the strategy, to talk to all of our stakeholders about the changing strategy to, you know, acknowledge we had the correction acknowledge that you know what we were doing wasn't working as we had expected. And that's what you know. That's what that value is in easy and scrum. You know to have the courage to do those type of things, to make those hard decisions and to have sometimes those difficult conversations and to acknowledge sometimes that things are not going how you expected him, how you expected them. All right, so let's go. Unless we want to The third value, which is focused again. This has to do a lot with the focus on execution and that we're looking at a very short pier of trying time frame, which is our sprint, right. So, you know, in scrum, we're not focusing on you no longer term deliver bowls and kind of like we're trying to not look at that. You know, the big picture all the time, but more look at the short term and full have a strong focus on the short term delivery. And that's why this is one of those key scrum Bali's openness we talked about before. And this is very closely related to transparency to people you know, being able to visualize what everybody is doing to people being, you know, able to talk to each other. And of course, this relates to also think that we saw before, like the peelers on the principles and then finally, respect. Respect is definitely a big value in in scrum. And it's, you know, we encourage people to be toe speak up on to always be respected, regardless off them having a different opinion. And we actually love that inscribed. We actually love people having, you know, different opinions are, you know, we're open to that were very flexible because it we need to change something and scream. We're gonna do it, you know, if something's not working well and you know, people have that openness with us to talk about it, we're going to respect their opinion. We're gonna take it into account on if we're If we feel on a scrum team, we think we need to make change. We're going make those changes really quickly. We're not gonna wait until the end of the project where everything's falling apart. We're gonna do this change even before we started explained, All right, so that's what you know. That's how they that's where the those six scrum values Um, these five scrambles are all about this where these five dollies scrambled eggs are all about, and I think that they said before they're pretty self explanatory. And by now you're probably thinking, Well, why do we have to even talk about peelers and values and principles? And I'll tell you why. I'll tell you why. You know the reason is because scrum beyond being a methodology or a framework for doing things it's actually also a culture. Here's here's a little secret for you, and I want you to take note about this. Crime is political culture, right? And you build culture with things like principles with things that values with things like peelers. All right, so I know this sounds of it. Sometimes when people look at this, it sounds a bit like a theoretical, I guess. And some things people see it all. That's just something that it's up there in a in a piece of paper or, you know, something that that's up there, but it doesn't really happen on on the ground and practice. And actually, you know, that's what I want a challenge in your mentality. If that's what you were thinking as they were going through these lectures in the courses that actually in scrum, we do apply this, you know, actually inscribed. We do believe these actually inscribed. We build the culture around these things, right? Because all of these actually interconnected builds. Trust on trust is super important for us to deliver. What we want to deliver on time on budget on exceeded everyone's expectations. And you're going to see these guys that when people are working together in scrum, they start to develop that a really strong relationship with each other because you're applying these principles values on because this pillars are holding all of them together. You know, in a very, very collaborative and comprehensive way. And like I said it just over time it starts to become a culture. People get into it after initially, of course, because people are learning scrum. Some of these might not be immediately reflected off because they're just getting, you know, themselves familiarized with the culture off scrum and with the different values, principles and the different peelers are part of it and just different artifacts components . You know, the terminology. Something's is just different for people as well. But what you're going to see happen over time, as people are going through the different sprints, is that people start embracing these very strongly on the reason why people embraced is. And like I said before these guys, not a coincidence that scram is the most popular, agile methodology out there. The reason why it becomes, you know so strongly ingrained in the culture and white people you know, start really getting on on the bus of scrum is is because they see the value in it is because they see that things are happening a lot faster. Verses they were before you implemented scrum or verses behold before would when you were working with traditional product Mashburn methodologies. So that's why people really like it. And I'm not just talking about management, by the way. You know, of course, management is gonna love anything that's faster on the delivers results faster. That's that's pretty obvious to me. An amateur, it's pretty obvious to you as well. But I think you know the reason why people on the ground people that are actually doing the work really likes scrums because they see the benefit. You know what? People are always gonna like things where they see the benefit for themselves, where they see the benefit for the rest of the team. Where do you see the benefit for the baseness. What? They see the benefits for that costumer. They're always gonna love those things. And that's why it's crime is so powerful. And I'm sure that as you're working with it, you're going to start seeing all of these and you're gonna start becoming more and more. You know what's come, advocate And some of you, you know, going through the scores might actually want to take on the role of scrum muster. And we're gonna took a little bit later on more about the role scrum master on. It's definitely, you know, one of the path is one of the paths that many people want want to go into, and it's a great path, you know, there's a lot off job opportunities out there for scrum masters and for people that know Scrum, you know, it's a very big in demand topic. You know, there's a lot of jobs out there for people that wanna apply agile and scrum. All right, so I definitely I guess hope that you know, as I've talked about this, you realize and you know these things, E I guess in your mind and in your heart that even though we're talking about these values , principles, dealers and so forth. It's not just the year it's actually practiced on. It's actually building up that culture. And I think you know, the more you put into practice, the more you understand what I'm saying with this and it will make more and more sense to you once you see it in practice and when you once you actually start applying these yourself. Now in this lecture, I want to cover scrum resources that are out there that are super valuable for you to review. And I'm not gonna go into all of these into detail in the scores because you know, it's something you can research on your own. And this is the scrum crash course and the scores. You know, I'm covering the key concepts and everything you need to know about scrum. Part of that is you knowing that there's a lot more resources that you can get access to, and most of them are free, if not all of them. And you know you can find things like the scrum guide online, and you can either look at the Web site or you can actually just downloaded as a PdF. And I'm gonna put the links year for year so you can go into each and every one of these valuable scrum resources that are making a valuable for us part of the scores. So the scramble guide, like I said before, it's the Bible off scrum and you can find that when you go to scrum that or you'll find there on that scrum that or website the scrum guide and access to it. And you know how to download this Crumb guide or just look at it if you want to look at it . But like I said, all seem to do all of that here in the scores and this crime alliance still orig. This is another resource that you can access and you can find a lot of valuable information . And by the way, a lot of them have some little short videos that I'm sure gonna find really useful and valuable that it will help you understand everything we've covered in the scores, even Mawr. And it's always good, I guess. To see you know and to access information from different people in different resource is because it's just allows you to complement your learning. And I mentioned before when we talked about you know, the origins of Scrum that these two, you know, scrum that Oregon Scram Alliance. You know, the fathers of Scrum, you know, have actually also either founded or co founded, you know, scrambled or scramble alliance or on the sometimes they're still even very active in those in those groups as well. And scrum study dot com. He's another place where you can find information about scrum. You know, there's also and certifications there and pretty much all of these different organizations or groups that have come about to share knowledge about scrambles to offer their own certifications. And, you know, if you ask me whether you need to get them, I don't think you have to. You know, I think you already know what you're going to the scores. You're pretty much I'm gonna learn really anything to different in any of those other courses. They're offering you there. But you know, if you do want to get those certifications, well, they're out there on there offering different pricing options for you to review and then to explore, and that's entirely up to you. But, you know, feel free to, you know, after you finish the scores, put it on your CV. It's, you know, it's a scrum certification that you now have. And, you know, like I said, I'm gonna make available for you different. Like all of these resources, I'm gonna provide the links for you and I'm gonna allow allow you to download templates. I'm gonna make a little templates for you on, but also gonna recommend different free scrum courses, arrival courses that you can take and we talked about before that you can also search from my crash course. You know me If you if you want, explore that other courses well, you want to learn more about agile and the scrum body of knowledge, The S bug. This is also something you confined And it's a bit of ah, I guess a bit of up. If you think about the Pam Bach in the P. M. It's a little bit similar to that, but of course, different. And it's just something else that's available for you for a consultation about, you know, about scrum and then finally last but not least ideal cavey dot com. And this is something that I founded in 2018 to share knowledge and spread the word around the world on justice. I'm advocating more arm or, you know, in different countries and different businesses about John's Crumb. And if you go there, you're gonna find a lot of free information. You know, pretty much everything that are having. Nigel kb dot com is free. It's also very active community, which you could join either, you know, on the Facebook group or on the edge. Okay, be wet side website itself. And yet these are all really, really valuable resources that you can explore on your own. And I'm gonna like I said before, put all the links and everything there for you. 9. Scrum Aspects and Scrum Strengths: so the scrum aspects are organization, business, justification, quality, change and risk. And when we talk about organization, this has to do with how this crime team organizes. It sells for delivery and different roles that are part off scrum, which we're gonna cover later on. So don't worry too much about that. The key thing here for you to know is that there is a type of organization what we're talking about, scrum, which relates to different roles and how they work with each other. The business justification is basically why we're doing this right. This is the aspect that we're trying to coral. We talk about business justification, which of course, is something that you should have answered before you even started the project. So this relates to something some things we call in, you know, in the agile world and in the scrum world, sprint zero, which is before we even start doing any of the work. We need to understand why we're doing it. You know, what's division where we trying to achieve and so forth? Quality in the scrum world when we talk about quality, is just making sure that whatever we're delivering, it's actually meeting what we could see. A rare acceptance criteria, right? Our acceptance criteria, which is what you know, before we could see their user story is done on, we actually, you know, have gone through that except acceptance criteria and check that he actually meets that acceptance criteria on that. It's up to, you know, the liberals off acceptable quality standards that we want to delivering the work that we're delivering and change. You know, we've talked about this before in In agile and scrum. We're adaptable and we're flexible and in scramble, actually, welcome change. You know, if something for example needs to change for the next print, we actually change it. We don't wait until the end of the project or until the next project feels on something is not working as it should. Then we change it. So we embrace change and scrum, and we also help, you know, people embrace changes. Wells, you know, we're advocates off positive and constructive change in scrum and you know, in last but not least, we want to boast about risk, right? And there's always gonna be risk when you're delivering something right? You always when you're delivering things, there's no small, medium, large and complex risks that are in both. And sometimes you know in you to analyze those weeks and understand how you can either many minimize them, mitigate them or eliminate them if you can. But you know, in scramble, we're thinking about risks. Were thinking that always in a positive and constructive way. So we're thinking about Are those risk actually mawr Opportunities, Opportunities for us to do things differently, opportunities for us to reflect on things we might have not considered on opportunities for us to prepare in advance before we actually do anything so that we prevent things that shouldn't occur. All right, basically, that's what we call when we're talking about these different scrum aspects. Now, when we're talking about scrum strengths, we basically are thinking about five key things. Continuous delivery, an improvement compartment, cross functional teams, self organization and focus on short Tim objectives and an interpretive approach. And we've already covered pretty much all these, in essence, through the different lectures in the course on I'm sure you understand these by now, and all of these things that we're seeing here are things that make scrums so powerful, and that's why I've always said before and you've heard me say this multiple times before. That's crime is so popular worldwide because we're you know, these things deliver a lot of value for the business. These things liver a lot of value for the team and this thing deliver hello value for the team members themselves as well, you know, because when you are part, make decisions and yourself organized and you work with people from different areas and you continuously delivering continuously improve and then you eternity Vly, bring and put on value, you know, on the table. Well, people value that and appreciate that. And that's why it's crumb is so powerful and these are ingrained strength off scrum. 10. Secret 2 of Scrum: secret limit to off Scrum is that you can actually combine scrum with waterfall or any other project management methodology in what we called ah hybrid approach. And why am I saying that this is secret Number two on? Why am I talking to you about this? Because you will not hear about this anywhere else or it's rare to hear about it. You know when you look at theory or you look at articles because most people talk about scrum, you know appliance come purely as you would like theoretically. But the reality is that in practice it sometimes makes sense to actually combine Waterfall , which scrum. And that's why this is a well kept secret because not many people talk about it, but they still do it. And it's one of those things that when you look at a different businesses, you might find that they're applying. You know, 20% of their projects are spurious. Kreimer, your agile 10% might be water ful, but actually that other 70% he's a hybrid project and that means that they're combining water full and scrum to monitor projects. And how does this work? So how this is working practice. Well, it's actually quite simple. You might do the initial face of the project with Waterfall. And then when you actually get to execution implementation, you switch to scrum so you can have your daily stand ups. Your spring planning. You're retrospect, thieves and so on. So that's it, guys, that secret number two. 11. Quality in Scrum and Change in Scrum | How to manage this in Scrum: So before when we talked about quality and scrum, I mentioned acceptance criteria, right? If you guys remember, I talked about acceptance criteria, and this is something that is super important when we're talking about quality Scrum, and that's as not considering something actually done when we've actually haven't checked that, it means that acceptance criteria. The other key thing when we're talking about quality and scram is that testing is that often not just at the end. It's also not just on a particular facing the project, right and he's also guys is a huge difference. When you're thinking about scram is a methodology versus traditional waterfall ways of managing projects right like that. You know, like the PM I and you know, the Pembroke approach. And I've talked about this before, right? And this has to do with, you know, in traditional product management. When you're testing, it's actually a facing the project on generally comes after, you know you've done already discovery. You've done planning before you start your execution, you do a bit of testing, and that can last for a few weeks or a few months. And then after you're a few weeks or a few months of testing, you actually deploy right? And so it's a very kind of like set time frame where I said, period of period or phase in your project in traditional. I'm talking about traditional product management here when you actually test something and then you just release it, right? So it's sequential room where we talked about and we saw that graph before about the skateboard and the car on at the top you had. You know how you go from, you know, the wheels to the actual car in traditional water, you know, waterfall product management while testing is that, you know, you know, face that process whilst in scrum testing is actually done often not just at the end. You know, we do it all the time in the different springs, You know, that we're delivering. We're actually testing us part of those prints. So this is why you see these cycles and and these are rose in diagramming inscribe because you're iterating and constantly, you know, delivering and as your iterating unquestionably there delivering your also testing eso. Another key concept off quality and scram is that it's not just the responsibility of one person Okay, So in traditional waterfall project management, generally there's a tester or a test lead. And we generally put a lot of responsibility on off the quality of what is being delivered on those people or on the person that is doing the actual work themselves, right? So in scramble qualities, responsibility of everyone you know is the responsibility of the team as a whole. We all want to make sure that whatever is me being delivered actually meets the acceptance criteria we have read out on as a team and, you know, in scrum a lot of times other people are testing. It's not just a tester. It could be anyone really in the scrum team on we. Actually, I want to make sure that, you know, the people that are doing the work feel supported, that you know, there's fresh satisfies, looking at what you're doing and helping him out and making sure that everything's working as as we're expecting and it made standard. It does not seek perfection, right, so you mean scrum. And this has to do with a poor, agile concept that we call the M V P, or a minimum viable product and also has to do with anarchy concept in ideal and scram which moved we're talking about Keep it simple, right? So we don't want to over engineer things in scrum We don't want to do things extra that are not really necessary or that are not really required When I keep it really, really simple meet the minimum You know those minimum standards that you don't get me wrong We're not compromising on quality We still want to deliver it high quality things but we just want to make sure that we don't over engineer it That's what this is is referring to when we're talking about you know, this concept off off, meeting those standards and that seeking perfection in in scrum and then continues improvement. Right, So we talked about you know, these again This is a core concept ing in scrum, you know, continues improvement. Either it alternative development right on these continuous improvement is part of what we call, you know, re trolling in scrum that are retrospectives right which are a bit off, like our lessons Learning scrum which, unlike water for project management that generally you know, they do these post implementation reviews p I ours and lessons learned sessions at the end of the project which could be a, you know, a year than the track in scrum. We do this exercise after each and every single sprint. So it's a continuous improvement exercise and it's beautiful. I love it, you know, it is one of my favorite things about scram because we're constantly reflecting to improve on the next print. And you know, it s you you already know. When we talked about the history of scrum on that scrum having you know, Japanese roots, this is something that is very, you know, ingrained ing in the Japanese coal trick. Japanese people, when they're working on things, they're constantly reflecting on that, you know, they're constantly reflecting on how they can do them better. Eso There's one of the reasons I really love the Japanese culture. You know, we have so much to learn from them and we've already learned so much from them in the world . And a lot of the, you know, the biggest methodologies and a lot of the biggest concept that we use worldwide nowadays come from Japanese culture or things that have Japanese roots on for me. This is no different. You know, when I think about continues improvement andare retrospectives and our narrative approach and scrum. I see it you know something that that delivers a lot of little value because we're not waiting until the end to actually make those changes to our delivery where we're making it , making them on the fly as we go on. And that's, you know, the core on hard and essence off scrum. So when we're talking about changing scrum Onda, we talked about this before, right? I said it's actually welcomed its accepted right. So we were flexible with our scope with our delivery. And you know, if people are from the business or stakeholders or a product owner arguing a speed bucking , you know that we should be making changes or that we should be doing something differently . We don't complain about that in scrum. We actually listen to them, we hear them out. We understand why they're giving us this feedback and we then, you know, make changes to our approach if we need to. So we're very, very, very open. You know, we talked about when we're going are over principle values and peelers. Transparency is also really important scrum. So we, you know, accept and embrace change when went required and customer feedback is incorporated into the liberals. Right? So we're constantly, you know, reflecting on our retrospectives about what is that feed but that we're getting on from the customers. And how are people you know, embracing that change those deliverables and is it working as we're expecting them? And you know, if something needs to be adjusted in our path in the way we're doing things we actually adjusted and also made when needed. You know, we don't want to make changes if they're not not really required. So in scrum, we want to keep things always really simple. Always, you know, continues the UN Interrogative Lee improved continuously an iterative lee deliver and we don't want to make changes. It's not really required, right? So we don't want to reinvent the wheel ing scrum. You know, if something is already being done, its work and we can learn from that will take advantage of that in scrum. You know, if if if we see something is working fine as it shoud and there's only for changes, then we're not gonna make them you know, we're not gonna make them because that's that would be, you know, going in the opposite direction off. I want to be doing instruct. So that's why you know, when we're going through our retrospectives, if there's something that is working well, we keep doing it is you know, it's just only logical writing. Something is working well for you. Why would you change it? And again, this is one of the things I really enjoy about Scrum is that we are constructive and possible change. We accepted, you know, we incorporated into what we're doing, but we don't really do it unless it's really necessary. That makes sense. 12. Risk in Scrum | Managing Risk in your projects with Scrum: and we were talking about risk in scrum. We basically want to make sure that we have those risks documented. Right, So we want to make sure that those reason are documented. So they're identified, they've actually being assessed, and they've actually Bean responded or action. And we're talking about risking crumb. We want to see their basically two factors. What is the probability of occurrence of that? And once we've but says the probability of occurrence of that, we also want to assess what is the impact in the event of occurrence. Right. So if that risk actually became a reality and not a risk any longer, but actually happened, why would that mean What? What's the impact on that? So, basically, these are the key things that we want to do when we're, you know, working in its crump. We want to make sure that the risks are documented. We've actually assessed them, understood them, You know, I clearly identified, you know, how likely is that to occur? And if that actually happened, what would happen? What would that mean for us? And then what would we do? Right. So you want to have that documented? I'm generally by the way, most most are scrum teams would have these in, you know, in a risk love. That is generally just an Excel file spreadsheet in Google Dogs or something like that. But you also see a lot off scrum teams. Put these on trail. Oh, if they're using trail oh, or derive their using Jiro Or they might put it on planet Earth. They're using Microsoft Planner. So there's many different tools out there for people to document risks and things that are you might want to document. When people are racing at risk for the project is you might want to run document the date in which the risk was raised, who raced it right? You know, which area is that person from? And the information that we discover like What's the risk in itself? So the description of the risk, what's the likelihood of occurrence on? Do you know you want to document whether that's already been taken? Care off. It's already been action. It's already been considered. So those are the things you want to make sure you've incorporated that as part of your I guess your risk log where your you know you want to make sure that the research captured and then they're actually action. And in terms off, if you know, the team needs to take action to reduce those Reese to mitigate them, to eliminate them, that they have bean effectively closed, if that makes sense. So that's what we were looking for when we're analyzing risks in scrum and in essence, I guess that's not too different to what you would normally do when you're working on any project with with any type of methodology in scrum, I guess that you think you're being you're gonna keep that very process very simple, very lean very to you know what's really, really required. And you're gonna You're not gonna be eating your We talked about simplicity and scram, right? We talked about keeping keeping things simple. So that's just, you know, the core, in essence, off any agile methodology as well. Or most of it that would take There are some things that are a bit more robust in complex ng. You know, like when we look to the umbrella, the ones on the right, you know, such as such a safe or diaz them. How will be the more I guess complexities and structures around them. But in general, when you're talking about scrum, you want to keep things. Andi, Most agile methodologies you wanna keep thanks to a minimum. Right? So I by that I mean again, like we talked before. We're not going over engineering. And we're gonna write this really long document to document or risks. We're gonna keep it, really, really to a minimum. Really, really simple. 13. What is Scrum for? | The real world, real life applications of Scrum: a question that comes up often before people actually even start working with scram is what they can use Scrum for on. We've already covered a lot of these, actually in previous lectures off the course, which is, you can use Crumb to deliver value, often to delivery, interrogative lee and to continuously improve. So by that it gives it because the time frame is short to writing, which you're delivering. It gives you a lot better control on the living things on time and on budget and anarchy. Thing that we talked about before is that you can actually use Crumb across pretty much any industry and across pretty much any type of project small, medium and even large projects. Yes, you can use them also on, you know, marketing projects, sales projects, procurement products. Like I said, pretty much any industry and any area would benefit from actually using scrum. Now, that doesn't mean that you want apply scrum for every single type of product out there either, you know, because it's not a one size fits all, and I don't think there is any project management methodology in the world that he's had one size fits all Sometimes you gotta take a hybrid approach. And by hybrid I mean, you've got to combine different project management methodologies. And sometimes, you know, it just makes more sense to work in a waterfall fashion because off the context off the business, because off the time frames for the Lavery or because it's just designated, you know, methodology you gotta work with in the business. And there's not even a discussion around looking at other options or other ways off, you know, implementing things, not saying, of course, and the many wrong that you can't have a chat to management and share with them. You know, hell heels. And here's an alternative approach, which I think would work better. And this is why I think it would work better when we could do a little Pilo thoroughly to proof of concept and actually recently had up. You know, I shouldn't of mine who was thinking about implementing scrum Andi. She wasn't exactly sure how to starting her environment. So what I said to her Waas Well, it seems like you have a really good idea of what you want to do, and the main thing is that she works in health and she works in this laboratory and and I was saying to their where Well, I looks and sounds like your team could benefit from scram if you implement that an initial pilots now with all of your costumers but with a particular group of customers on. But they were basically just trying to work in a more efficient and a faster way and reduce , you know, the key. Oh, things were sitting off work that she needed to be done. So I said, Well, just start with a proof of concept and showed the results to management. And then you guys can decide whether there is a lot of value for you in your contacts and in your particular environment to implement scrum. But generally we it is. You know, generally, what I see on the field and as I'm working in, you know, in different countries and different projects and with different people are all over the world, is that they most of them actually benefits from scrum, and once they understand what they can use them, use it for a lot of them actually want to use it right, because it allows them to reach your goals and objectives faster and it allows them to provide validator and customers on gives them flexibility and adaptability in the different things that they're doing. And you can also use crown for, you know, research and to identify viable markets, technologies and capabilities you can use, you know, scrum also for developing products, services and enhancing those parts and services, making them better. You can use scrum to release products on enhancements frequently and often. And we talked about this before. This is the core in essence, off scram. You know it narrative continues delivery, an interpretive continues improvement and you know you can also use crump development, sustained cloud and operational environments for proc use for those that are working with I t. And you know I t products and services using the cloud. And also last but not least, you can use crumb to sustain and renew production services. Rightto maintain a competitive advantage in the marketplace for those products and services , and to actually refresh them on. Do I get a good example of these? Could be your company website. You could use Crumb to, you know, update the website that has that and make it you know, nicer than East Today on. Yes, I know this and giving right now, you know, a 90 example. But that doesn't mean that everything has to be on I t projects. Like I've said before, you can apply these across many types of industries and no cars, many types of projects. It's actually working and talking with a colleague of mine that is, you know, he's into property and property investment and property management on he was applying, you know, scrum principles in the work that he was doing with his team around how to choose those new properties that he's gonna be investing on. So I you know, I've seen people you know apply Chris Crum to plan their weddings. I've seen people up applied scrum principle since Crumb to, you know, work on operations projects, procurement projects on, you know, I was involved actually tender for a procurement process a few months back, and we applied ideals, principles, and we split our tender process into user stories and springs and actually went through the whole process, you know? You know, I got three month period for something that usually tooks 12 months. You know, that was amazing. It was really valuable for us. And we went and we were able to go through that whole tender process in a couple of springs and make a decision on which was a vendor that was gonna provide that service to us and we needed in record time, you know, we did it in three months instead of 12 months, and that was really, really a great accomplishment. And I feel really proud of that. And I'm sure that as you meet people that are working with Scrum, they're gonna share really interesting and really great stories with you about how they delivered a lot of value really quickly and a lot faster than they were doing before they even started working with scrum. 14. Secret 3 of Scrum: secret number three is that scrum retrospectives are super powerful. They're actually at the core essence and one of the most important aspects off Scrum as a methodology and as a framework on I talk about this from practice. What you're gonna find out is that when you're you're doing your retrospective regularly as part of your springs or when you finish your sprints, then you're going to see that you're actually gonna be changing things for the next spring and you're gonna be continuously improving and making changes that will have a better outcome for you in the project and will allow you to deliver faster to meet those goals to meet those objectives. So what I'm trying to say is that make sure you take full advantage of your screamer perspectives because it's such an important, agile re troll, and you're going to see that. Like I said before, you will make a huge difference when you're actually putting into practice those lessons learned in your next sprint and I'll give you a perfect example. Not that long ago I was working on a project on. After a six weeks experience period, we had Onley reached 3% off execution. Now that is a really in low number. After a six week spring period, we were actually aiming to be at around 60 70% by that time. So after one of the retrospectives, we reflected completely changed approach and strategy. And in less than a month we went from a 3% execution rate toe a 93% execution rate. And that was the how'd come off a retrospective. And that's why this is secret number three off scrum. 15. Scrum Rituals and Scrum Roles: the scrum rituals that we're gonna cover in the scores are a daily scrum. Spring planning. Sprint reviews retrospectives on backlog, refining or back look grooming. And before we go into each and every single one of them into details. So you understand what they all mean in the scrum world and how you implement them in practice. The key thing I wanted to take away from these is that they're all part of what makes up the scrum culture. Okay, that scrum agile culture is part of that. Are these rituals right? And part of what makes that culture work and function are that these rituals are actually put into practice and that we actually have disciplined in actually doing them. Okay. And the more you do them, the more naturally will become on the more familiar we will become for you on for the rest of the team. And the more you know, you do them, you're the more value you will seeing them. Trust me. Okay, guys, we have already seen by now in these cramp cores, Scrum is very, very simple, right? It's all about simplicity, minimalism and delivering value. Often they quickly on what allows us to do that as well. He's dating scrum. We actually have three key roles that are called the Scrum Master, the owner and the development or delivery team. Okay. And we're gonna cover each and every one of them in more detail. But as you can see as everything else in scrum is very simple, right? We're just talking about three key main roles. 16. The Scrum Master: So let's start with the role of a scrum master, which is a key role in scrum. And if you're wondering whether anyone can take the take on the role of the scrum master, the answer is yes. It doesn't have to be, you know, a particular pair person designated by the business or that doesn't have to be someone that have that official role in New York. Structure off scrum master. It can be pretty much anyone within the project team as long, of course, as they actually have really good scram knowledge and a really good understanding off scrum as a methodology and off ideal principles off course. So this grandmaster is basically someone that is there to facilitate and to advocate for scrum within the business. And it's someone there's gonna lead support guide and help these Crumb team. He's also someone that's gonna remove roadblocks, issues or impediments for you. So he's actually going to support you and support, you know, the scrum team, making sure that they meet their goals on time and on budget on he sold so someone that is very active, all the different rituals that are part off scrum such as daily. Stand up. You know our daily scrum if you want to call it like that and retrospectives, right But the scrum master is not a traditional team, lead or project manager, although it could be a team leader, project manager that takes on the role of scrum master. Like I said before, pretty much anyone can take role of scrum master as long as they have enough scrum knowledge and you are very familiar eyes with agile methodologies and scrum as a framework . So the key difference from my perspective off you know, the scrum master versus other key lead roles in the businesses of the scrum Master is a servant leader, so he's not there like two in the traditional sense. Tell you what to do. He's Mawr there to help you do your job, you know, to remove things that are impacting what you're doing or things that are impacting. You know, the delivery team, right? But he's not there just to, you know, kind of like he's not there. Ask your boss if you if you want to think about it that way, he's not there to do that. He's more there to facilitate to ensure that you have everything you need to ensure the scrum team is focused on delivering, delivering on time to ensure that there, you know, the team is actually keeping up with the discipline of going through the different scram re trolls and he's there to work very closely also with a product owner. I'm making sure we're focused on the right priorities and we're taking into account feedback from the product owner. You know, the customers that he represents or from himself if he's the customer. And ofcourse, the pro corner is constantly liaising with other people from the business. So the scrum master is constantly and working closely with the proton or to ensure that it's taken into account in You know what the team is doing and you know he is also, you know, the role of the scrum master and we talked about this before is also very big on facilitating right, you know, making sure that the things take place and making sure that everyone is following those agile values, principles, dealers. And he's basically an advocate off scrum. You know, we think dis krumping and making sure the team is, you know, constantly and continuously improving constantly and continuously iterating on delivering and that the team is going through, You know, the different springs, this plan, you know, meeting the targets and working with each other to the liver as planned. 17. The Product Owner: now the birth owner is gonna be someone that is gonna be working closely with the scrum master with delivery team. And he's gonna be someone that's basically gonna call the shots on what are the priorities that the team should be focused on based on the customer needs, right? Cause he's either the customer themselves or someone who represents the customer on generally the broke owner is somewhat that comes from the business, right? It's not really someone that comes from the area that you're working in, or someone that you always in a but a technical role or something like that. Generally, the owner is someone that has a business focus on, comes from the business on represents the business and our representing all the against the interests of the customer, the end user. And that's what you want to be. And that's who you want to be, the person that takes on the role in terms off being the part owner. That's what that person should be. And the owner basically owns the product backlog, which is especially and mainly what we're gonna be delivering. It's just everything you know as a whole that we're gonna be delivering and just keep in mind that brought back Look, he's including all of those user stories which, like we saw before, I pretty much where you're going, you know, kind of like the tests that you're gonna be working on that that is a part, you know, the pro pet look and the pro owner. Well, he owns the backlog, and he pretty much said something finds those priorities based on you know he's needed. If he's a customer, the customer needs if he's representing the customer and he can be, you know, working as US approach owner representing the business on different projects. But a scrum Teams should have, ideally, Onley one Perathoner. So you don't want multiple people trying to define priorities, kind of taking on the role off product owner you just want. You just wanna have one person that he's officially assigned and committed to be the owner for your project, and that's something that you have to identify even before you start the project. And that's generally a discussion, you know, with the team, and you know, the business or management around who is actually the key person that you want be making those decisions in terms, off priorities and what the team is gonna be focusing on. So, like I said that something that normally you would do before you even get started with work and making sure that you find that person is an important part off that process. The owner is basically that breach between the team and stakeholders and because of his role within the business, he's probably constantly and talking with different business leaders, different people that actually represent or working closely with your end customers. So he's that bridge is that person that brings that information across to you on? You know, what are the things that we should be focusing on? What's important for customers Off course that broke owner. You know, it's a different role within this scrum methodology so that it needs to be someone that is different to the scrum master. You should never have this crime. Master also played a role off the pro toner because it would be too much for him. It could be also, in a way, a bit of a conflict of interest and at the same time, well, there to a very different roles, with a different focus and yes, they're working very closely with each other. But generally people that are taking on the role from scrum master are people that are sitting within the side off the business that is actually focused on delivery, right? So within the different. I guess project teams were operational teams or support teams if any of those people have actually decided to take on the role of scrum master. But you know, the person is actually generally taking the role of the scrum. The scrum owner is somewhat that that he's actually coming from the business, representing the business side of things on the end customer. So again, like I said before to our different roles with their very different focuses, you know, the strong master on the throat owner and scrum they have ah, different, I guess focus and but they are working very closely together and the scrum master works very closely with the owner and helping helping the team understand what you know what that focuses based on his conversations with with the product owner and the broke owner, you know, he steers the direction of what is what is being delivered. Like I said before, he he is the one that calls the shots on priorities, and he thinks something should change in order. He's the one that's gonna make that decision, and he's gonna want to be the one that's gonna negotiate that with management if we need, you know, changes in Scott scope, funding or schedule because we're flexible in scrum. Right? We've talked about that before, and, you know, if something new comes up and management wants us to deliver something through a spring that we haven't originally considered, unlike traditional waterfall pretty punishment. We're not gonna show shy away from that. We're not gonna push back against that. We're just going to say that, you know? That's fine. We're gonna have that conversation without broke corner on. What are we going to the school board departed ties off what we have planned to do, or are we just gonna get you know, Boris funding And we're gonna, you know, adjust our schedule if we need Teoh upon approval from management. And that's what the book owner is there, you know, to help us, he's there to help us make those decisions and to have those conversations with those different stakeholders on management around around that type of things and such a scope, funding and schedule. And, you know, like I said before, he's the key person that is gonna help us make those decisions around priorities and focus and what the team is gonna be focusing on for delivery. 18. The Delivery Team: and last, but at least you have the delivery team. This is pretty much everyone else that is involved in this crime team on that is involving the process to make sure we actually deliver on time on budget and on track with our goals and objectives. And generally, you know, the libertines are typically between 3 to 9 people. These are the people that are actually doing the work. So we have here business analyst, developers, designers test. There's pretty much anyone else you know, architects that is actually involved in the work. And this varies, of course, project to project because you might have a project where you might need an architect involved and you might have another one where you might not need one on. There might be a project where, you know, because it takes a procurement project, you might need a procurement and all this involved. But let's say you're working on the finest project. You actually might need a finance analyst in both. I'm not up on a procurement person, So the delivery team, I guess that the composition of the delivery team is he's pretty much going to vary, you know, from Project to project in terms of who are the roles and the people within the different areas that are involved in the project. But you know that the key thing for you to take into account I guess atik t take away for you to consider is basically the people that are the delivery team are the people that are actually doing the work that people are are actually making things happen in terms of delivery. And you know, that can include us. Well, a project manager, business analyst. It depends. It depends, really, because sometimes you will see in some scrub teams that the project manager takes a roll off scrum master and that's okay. Doesn't have to be like that. You know the project manager? I could sit in the delivery team and not take the role on the off off off schoolmaster. So you know Scrum Master doesn't equate necessarily to product manager. They're two different roles. Although it is common and a lot off. You know, scrum teams will actually, a lot of product managers will actually take on the role of scrum master and they're actually being trained. A lot of them have actually going through the scrub training and trained themselves to become scrum masters. But again, you know, like I said before, that doesn't mean it has to be that way, way we know what we're talking about. The delivery team we talked about before self organization, an apartment to make those decisions on the what is being, you know, specifically delivery the spring down on what you know, the focus on what what's being done. And, you know the team is in part to make changes if they think they need to make changes on on the way there approaching something because off their what they reflecting on in their retrospectives. So again, you know, sometimes I get asked this question, and that's why I want to talk a little bit about it here in these in these lecture of the course, he said, Sometimes I get asked, You know, what's you know? What's the role of a B A or What's the roll off on architect? Or, you know, what's a roll off? A test serene inscribed on gets a key thing for you to take away from these parties that it's not really too different from where their usual role you know the the main key difference is that there are part of a scrum team. So because they're part of a scrum team, they're part of the scrum rituals and then they're following this camp. Principles, values Peeler's and you know they're working in a different manner. So instead of the traditional sequential approach, they're working together in an eternity of approach. On that the rules blur, you know? So the Rose Blur. I mean that, you know, you might have someone else that is not just a test very involved in testing in scrum, right? So we don't we respect. They get the traditional roles on the official role that person has, I guess, role title that they have in the organization. But that doesn't mean that necessarily they're gonna be doing on Lee that specific role or that specific role either. You know, that could be like I said before. It's a it's a project manager and he could be helping with testing in Sprint and that's OK . That's OK. That's accepted and that's welcomed in scrum. And you know, the delivery team, like I said, well, very in composition from project to project on that, something that you will need to define before even get started, right when you're thinking about who needs to be involved in this project in terms of delivery and those are the people that you want in queued in your delivery team. 19. The Scrum Master Service to other roles: alright guys. So we already talked about the different roles that are part of scrum. But in these part of the course I want to go a little bit deeper into the role of the scrum master giving and I know many of you or some of you might actually want to pursue the role of the scrum master And there's a lot of job opportunities out there for scrum master's. Okay, so let's talk a little bit about the scrum master service to the owner. Basically, like we said before, the scrum Master has a really close relationship with the owner and they're constantly communicating with one another around. What are the priorities? Why they should be focusing on if there are risks that they need to mitigate manager, eliminate and basically you know everything and anything that is delivery related. They're discussing it and they're reviewing it together and because the scrum master is a facilitator in general, off the overall process, he's also kind of a beautiful coach, right? So he's gonna be helping the Perth ordinary feet, you know, the broke donor or the person that has been assigned to the role of product owner doesn't have much experience with Scrum. The scrum master is there to help him So the cross Scrum master is gonna be walking in through the methodology. He's gonna be explaining the different terms. What? They mean he's gonna be making sure that the Brook owner feels comfortable in that role of owner. He's gonna make it. Make sure that we're actually practicing agility and everything that we're doing. He's gonna be facilitating those crime re trolls, the scrum events and he's gonna be making sure that everyone is on the same page in turns off, while the broke owner wants us to focus on. So that's it. That's mainly what the scrum master he's going to be doing for the Perathoner. Now let's talk about the scrum Master service to the development team. It really evolves. Are a lot of round coaching, facilitating, helping, supporting basically removing anything that could impact the delivery of the delivery team . That's pretty much it. So the scrum master is gonna be working very closely with the delivery team on making sure they are following the actual rituals, principles, values, peelers, making sure they understand the different terminology and scrum making sure he's constantly coaching them and helping them in their scrum journey on the scrum. Master is going to be working closely with the team as a whole with different individuals to help them in the scrum journey and facilitating the different scrum rituals and making sure that if anyone in the delivery team is having any issues or you know, impediments or roadblocks, well, the scrum master like we said before, he's a servant leader, right? So he's there to help them. So it is there to help them, you know, with their job making it easier for them making it smooth that if something is actually impacting them and it's out of their control, where the scrum master is there to remove that he's there to get rid of that roadblock on, help them get on with the job. But also I think most importantly, the role of the scrum master and the service it provides to the delivery team is making sure they're staying focused, delivering on time, interrogative Lee and continuously improving alternatively and continuously growing maturity and continuously delivering value for the business and last. But at least let's talk about the scrum Master service to the organization basically the scrum Master is there to help champions scrum in the company. So if someone that's gonna be advocating for scrum on helping the business plan out the scrum projects that different, you know scrum teams are gonna be delivering and he's also gonna be leading scrum adoption within the company. He's gonna be coaching people. He's gonna be helping people understand the terminology that benefit the value, most importantly showing them in real life and in practice what scrum can help them achieve and how scrum can be valuable for the business of the whole or for the company as a whole to deliver projects on time on budget and a lot faster than you know, the usual or traditional product management methodologies. So, like before, you know, the scrum master is not providing just one single service to the business or to the company . He's actually providing multiple things and he's actually adding a lot of value to the business. And that's why right now there's a very high demand for Scrum Master's worldwide. You know, people are hiring scrum matter. They're actually you know, and this is not something you know, that I'm making up for it something you can actually google yourself or, you know, if you go to seek monster whatever is the job side that using your country. If you search for a scrum Master, I'm sure you're gonna find a lot off. You know, job opportunities come up because it's actually ah, role title in a lot of companies are actually four million officially creating the scrum master role within the company. And you know, there's also a lot off consultancy companies out there hiring scrum masters because a lot of companies want to go back to those consultancy consulting firms and that get, you know, a scrum master, helping them out with a particular problem. They're trying to Sobel or helping them out the lever, a particularly project that they're trying to deliver. So basically, I guess the key take away for for you around these is that there's a lot of jobs out there for scrum masters and that you know, the information and everything that you're learning any scores will help you become a scrum master and that you can actually take on that role and start making more money and make a career change. If you that something that you want to pursue again. It's not something that you don't want Don't have to do, you know, if you don't want to do it, you know you can steal, Just understand. I know the different things that are part of Scrum so that you're working on this ground project. You actually understand what it's all about and it makes sense to you. And you don't feel like, you know, like, completely lost out there already. If you're working on a scrum team, you can help the team reach its goals. 20. Secret 4 of Scrum: secret number four of Scrum is that we can actually prioritize our user stories by focusing on the minimum buyable product, low hanging fruit and what maximizes value for the end customer and for people that are benefiting from this project. That's what you want to look at when you're looking at your part of backlog and under sprint back. Look on defining your priorities. So make sure you're thinking about those low hanging fruits because part of our trying to achieve in scrum is showcasing and delivering value quickly continuously on often. So the part off that secret and what I'm covering in this specific lecture of the course, he said, You've got to think about the M V P so the minimum viable product. But you also have to think about those low hanging fruits. What are those things that are quick wins that we can actually deliver fast in the project ? And that is what you need to discuss with your scrum team as you're preparing to deliver your next print, look at those user stories and think about how you can logically group them together for the next spring and which of those focuses own a quick win a low hanging fruit, something that we can actually showcase to the business, to the stakeholders that we're making progress on the project. So make sure that you take note of these one because it's a really important secret. Alright, guys, see you on the next one. 21. Planning, Documenting & Estimating in Scrum: all right, guys. So let's talk about its planning in scrum. Like anything else in scrum planning is actually alternative and continues. So like traditional product management, in which planning is pretty much a phase of a project and it's done all in a particular time off. The life cycle of the project in scrum were actually planning throughout the entire life cycle of the project and it's a continuous exercise. So we do these right after finishing and sprint on before starting the next one, right? So of course, before we actually start our sprint, we go through the re troll off. Our spring planning on a spring planning session is generally, you know, it's generally a meeting. Which of these thes Crump team gets together with the scrum master and reviews what they're gonna be working on in the next sprint, right? And they look off course to the backlog, which includes everything that they're gonna be delivering for that product or service. And then then they take some of the user stories that are within that bag, look right, which we talked about before. We're going to talk a little bit about let about thes user stories but basically they're kind of like the tasks that you're gonna be working on that are coming off course from those requirements on. Then you review that with your scrum team and the final which off? Those user stories you're gonna deliver in the next sprint. That's basically what a spring planning meeting is. Our spring planning session is You're basically there to just assess from the Brokeback look or the service back. Look, whatever you know, you're back. Look off user stories. Regardless of whether you're delivering a product or a service, it's still that applies. The same concept still applies. You look at what you have there and then you define what you're gonna be doing next, right, and you look at your priorities and you also of course, look at what your goal. What are you trying to achieve in that sprint? And that's part off your planning process and you're planning exercise. And even though theory tells us that we can spend up to eight hours for a one month sprint , the realities that scrum teams become really good at planning their springs, especially after they've gone to two or three of them on generally what I seem practices that scrum teams spend, you know, Generally they spend less than an hour planning their next spring cause they know what they're going going to be working on. They already for me, they're with what they're trying to achieve and they kind of started guest senses. They're going through different sprints, about how fast and how much they can deliver right, which is called the Velocity right. We'll talk about that a little bit later in the course and then as they're getting better, you know, as they're getting better out other planning, they become, of course, faster doing it. But normally what I seem practices that the scrum team spent about an hour on their planning sessions. Now I also wanted to talk about documentation Is Scrum because this is something that often comes up on? There's a huge misconception around this with Scrum and that girl in general, which people think that it's Groman Angela, you don't document anything and that is a total lie. You know, if anyone tells you Oh, scrum has no documentation or agile has no documentation. Forget about that, you know, like that's not the reality. The realities inscribed steel document. You see, I want to be documenting things that are important differences. You want to keep it, Ling. You want to keep it short. You wanna keep it productive, and you only want to do it when strictly necessary and was strictly required. So basically, in scrum, we would never document something just for the sake of documenting it. So no documentation, just for the sake of documentation were really against that inscribe we're also really against. You know, those really long documents in which people document things for Let's say, it's, for example, of business case, and it's a 40 page business cage or, let's say, the solution design. And it's a 50 page or 80 page architecture document that nobody is going to read. We know guys that nobody reads those 80 page, 40 page documents. Nobody has the time for that. In the more than world everybody's BZ. Everybody has other priorities. People's parties are not all this. Everybody's working on different things. So you know these one thing that is so great about screaming scream. We turned those documents that are 40 pages, 80 pages and we turn them into a one page document that two page document off four or five page document. We keep it really, really lean, really, really succinct. We actually just captured a key information that we need to capture in those documents on. That's what you need to know about documentation in scrum that yes, we do it. No, we don't skip it on. No, we don't disregard. It's still important. It's still part of the process is actually like anything else in scrum continues its Tear it Eve and it's something that we're improving on the time. And it's not just something that we do once. Of course it is a live thing isn't static, but we don't focus solely on that and we keep it really, really simple. Estimating in scrum is about taking those user stories on assigned this those story points that we talked about before, So that's the process about how you estimate in scrum on you basically work collaboratively with your scrum team. The delivery team on you work together with the scrum master and as a team, you estimate and your sign story points with user stories, which allows you to see why they're going to be able to deliver in your sprint. That's pretty much it. Guys. It's really, really simple. There's not much to it estimating. And I guess the key point and the key take away and I want to leave with you when we're talking about estimating and scram is that it doesn't need to be perfect. Okay, again, the whole concept off, anything you doing scrum is that you generate and improve over time, right? So you don't have all have to have perfection. You don't have to be afraid of making mistakes. Don't be afraid Off estimating quickly actually encourage you to estimate quickly. I encourage you not to spend too much time estimating. I encourage you not to spend too much time thinking about when you're thinking about your user stories. Always these 305 receiver one, You know, like don't spend too much time on that. Go with your gut feeling on. I think the story points. We choose her story based on what you really think it's going to take and how complex it is . And again, don't spend too much time on it. If you're got your gut instinct, are your talking with your team and the team as a whole? fields. It's a five. Leave it as a five, you know, move on. And if in the next brain use at all, you know, maybe maybe way assigned five years or story points. But that was too much for that user story. That's okay. That's whether you have your introspective therefore, right? You're gonna reflect on that later on and you're gonna take that lesson learned that you know that learning into account in your next print and that's what scram is all about. You know, it's all about a continuous processing which were delivering and what you are learning as you're going through that delivery. 22. Delivering and Improving in Scrum: delivering in scrum is again interrogative and it's also continues on. It's quick and it's often so again, unlike traditional product management, in which deliveries a particular facing the project pretty much before go live and it's kind of part of what you're just doing before we actually kind of close up the project. International Product Management. It's generally one of the last faces of the project delivering in scrum. It's actually I'm ongoing process. It's actually that something that happens from the get go from the very beginning of the project, which is really exciting. And this is one of the things that it's sets scram apart from traditional product management. That that's what you're actually delivering from the beginning of the project, not just at the end of it or not, distorts the end like in traditional product management. And this is one of the key differences versus traditional product management, and this is one of the key reasons why business they call theirs CEOs, business managers and the business is a whole love scrum on the why they constantly want to adopt scrum practices in project management and in project delivery. And that's because weeks crumb, your Hillary Often you're delivering quickly and don't get me wrong. That doesn't mean that you have to deliver the first or the best top solution from the beginning right again these easy charity instead of sequential extradition product management. So you might deliver a simple solution initially and then build on top of that interrogative Lee and build a super robust structure solution more towards ah, future spring in the process. So again, this touches on concepts such a simplicity, agility. All of this is part off the core, in essence, off scrum. And if you recall the picture that we saw the beginning off the course we're looking at, we need to go from point A to point B. And we looked at the different ways in which we would do that using scrum which we initially had a skateboard. Then we had a scooter than a bicycle than a motorcycle and a car. So all of those different solutions are allowing us to go from point A to point B from the very beginning, so we don't have to wait until the end of the project to actually be able to get to point B . We can do it from the very get go right. The difference with that and the important thing there that scrum allows us to do is that we continuously reiterate the solution, making it better and better and better on throughout the whole life cycle of the project. We're delivering value to the customer to the end user. Whilst in product management in traditional product management, they would have to wait towards the end to see that actual solution towards the end. We actually actually able to get to Point B now. Another key thing we can talk about here is that let's think, you know, real life, real life examples in real life how these actually gets applied in real life. So let's imagine that you're delivering house, right? Let's think about a house. Okay? So you know how when you build a house, you gotta put the structure. You gotta make sure that the ground is fine to, you know, structured and stable so you can put the house on top off it. Then you know you have to paint it outside, painted inside, put the doors, the windows etcetera, right. And this is just a very simple analogy. But the point here that I want to make with you is that we could do a proof of concept, right? So before we actually even built the house, we could actually show what the house would look like to our customers so that they actually decide whether they actually want us to build it or whether they actually want to make any changes before we actually build it. Right. So how will we do that? Well, proof of concept, Right? So maybe we just do what? The sign. Show them the house or using modern technologies. We could actually even create a virtual reality experience in which we maris them into the house and show them how it would look like. And you know how the spaces would feel like to them before we even get to build the house. And that, of course, is significant. Why? Because if you actually built the house and say there owners or the people managing this project wanted you to change things in the house. Well, that would be a very expensive exercise whilst with scrum, if we showed them that you know that proof of concept and they wanted us to make changes to it. We could do it from the very beginning before we actually built it. And then that would save us a lot of time and a lot of money. And that's why this is so value on. You understand this concept about how we deliver in scrum, how we do it in a simple way quickly, often interactive. Lee is such a huge difference also versus traditional project management. And there, you know, there's literally thousands and thousands of examples that I could think about. But I'm not just I'm not gonna make this you no longer than it needs to be. The key point here is that when you're working on your on your projects, in life, in real life, just think about what is the first thing we could deliver. You see the prototype, he's well, let's a let's imagine you're trying to roll out, You know, a new process to the whole business, right? Let's think about a process. Let's say you're rolling out a new process to the whole business about how they should now use their new you know, the phone to make international phone calls, right? Let's say this is a change in behavior because they normally used to be able to call internationally, easily just white. You know, speaking of their phone and telling the country code. And for some reason now, business, that detective that people were abusing that on that it was being very expensive for the business. And they want it now. Put a process in place in which you need to go through a run approval request before you actually able to make that international cult. Well, in these real life example, right, If we're thinking about Scrum, how would you do it? Well, we the the way, if you actually seem results from the very beginning without having to wait until this is rolled out across the entire business. Well, one of the options that you in which you could do this, would be a pilot group, right? So maybe you just speak out. Let's say you have 10,000 people in the company that are gonna be impacted by this change. How about you? Pictures five. And then start with those five role of the process to them without making it perfect. Just has a really quick interational, really quick sprint and then checking the results before you move on to larger groups. So you're doing like a like a little exercise, right? And this is what we're going back to The concept of Sprint. It's a really small time frame for delivery the sprint, which allows you to show tangible results pretty quickly and again in your sprint. You're actually going something improving for the next one. You're testing your analyzing your planning. So right like this is allowing you to is an ongoing process in which you're every sprint after every splinter. Doing this exercise you're planning for the next one, you're reflecting for improvement for the next ones and so forth. And that's why you see this circles, that we have kind of like this. You know, these arrows that we have a diagram in in Scripture to just kind of convey that process that is a continuous process off iterating and improving, by the way, you know, don't get to confuse some things. You might hear people in scrum talk about iterations instead of sprints. That's fine. Don't worry too much about that. It's just accepted the same thing. You know, spring iteration. We're talking about a time box period to deliver something and you know, like officially when you talk about that, you go to the scrum strong guy, you see that they talk about, they do talk about screens. But you know, there's some people that actually use the word federation as well. So they're kind of common senior names and there were there globally. Both accepted, so the worry too much about that. The main thing is that you know that if they're talking about springs or eat a regimens have pretty much the same thing. Kind of like when when they're talking about, you know, deliver bulls and increments, right? So sometimes people talk about the liberals and increments interchangeably because they're pretty much comparing the same thing, right? Like what? What is the increment? Well, what do we actually built or whether we actually delivering the sprint? So it's pretty much the result, right? The end result of the sprint is the actual deliverable, or the increment like planning in scrum. Improving and scram is also continues and interrogative again, as you've already noticed. But at this stage of the course, continues Andi charity is pretty much the common thing going scrum, and that's because that's at the heart. In essence, off what scrum? He's as a methodology. So you're continuously improving, and you're often reflecting on how you can improve. And the way we do this in scram is via our retrospectives on. We'll talk a lot about retrospectives in a separate lecture, but basically think about retrospective like a mini lessons learned session that is happening after each sprint. And normally again when you're thinking about traditional project management and I think it's always important to contrast, Scrum versus traditional product management so you can see the big differences between them is that in traditional project management, generally, teams reflect for improvement at the end of the project. So after C X ponds a year, two years, whatever the length of their Project life cycle is at the end of the project, generally there will spend some time reflecting on improvement for the next project. And in traditional product management. This is generally called a lessons learned session, and it's also referred to as a P I. R. Post Implementation Review session and so forth. And there is not really a particular you know, I guess structure to that. Every project management team does it a little bit differently, but in essence what I'm trying to convey about the differences that's generally done at the end of the project. And unlike Scrum, in which we actually do this continuously right and we are retrospectives, which is one of the most important scrum rituals we continuously reflect, reflect for improvement on we continuously adapt for the next print. So we're continuously were visiting, kind of like what we did before what we accomplished, how we are tracking versus or targets. And then we adapt and incorporate those improvements into our next print. How we do that by looking at different tools and artifacts that were using scrum such as the Cambon board and you know, scrum charge such as a burned down chart and velocity charge which we're gonna cover later on in the course. 23. Secret 5 of Scrum: secret number five with Scrum is co location on. By that, I mean that the people working together as part of this crime team should be sitting together right next to each other in the same room. Now, this is the ideal scrum scenario and I know sometimes it might not be possible in your business and you might not even have that option. But ask the question, talk to your managers, talked to the business and see whether it's possible and face able to rearrange even temporarily as you're working through your sprints so that the people that are working with you on the project from different areas at least those are part of the key core scrum team are sitting together. Trust me, this makes a huge difference in your products. It will improve communication. You will make it easier for you in your daily stand ups and toe work together very closely with that scrum team to ensure that you're making those the liberals and your meeting those deliverables as quickly as often as we can and that you were working together and following the different scrum Rachel Spring symbols and artifacts in the best possible way. All right, guys, co location. Make sure you take advantage of that where you and when you can buy 24. User Stories in Scrum and the Scrum Kanban Board: Now let's talk about user stories and user stories are basically tests that we're gonna be working on in our sprint, right, But they come from business requirements that are returning the foremost as a block I need to block. So that block right, for example, as a project manager, I need to work on the project plan so that people can understand what we're trying to accomplish, or as how developer I need to create the home page so that that project team can see what it would look like. Now. It's a simple list is that and you're going to see that depending whether on whether you're using digital board or physical, can been bored, people will put their user stories. If they're using a physical board, they'll just write them down on a post it note and paste it on their scrum Cambon board. Or if they're using a digital tool. Well, they're stools out there that you can use to put your user stories in a digital fashion that people can move around and they can, you know, use their mobile phones or their decks, supporter laptop toe, work on the camera on board and update you know the product status throughout the sprints. And if you think about different tools out there that you can use, I definitely recommend trail. Oh, it's one of the free ones and it's great tool. I love it. It's definitely one of my favorites is not my favorite scrum tool that you can use. But there's also other tools out there, such as Ghira and Microsoft Planner. And there's many other tools that you're gonna find out there. And I'm gonna put links and everything in recent other resources for your hearing the course so you can explore some of those other tools that you can use injuries. Crump projects, you know, to know down all of your user stories on you know, just all of the user stories to gather. That's what we call the backlog, which is pretty much everything you need to new to do to deliver your project. And then what you take out off that to deliver is what we call the sprint right? The user stories that you're gonna delivery in the sprint come from the Brokeback look and again, another thing I wanted to note on for you, just for you to keep in mind. He said you know this, I guess this a structure off Assad blah, I need to blast. So that block, right, it's This is the theoretical structure over user story. But what you're gonna find out what you're gonna find in practice in the real world is that some things that becomes a little bit redundant, right? Because if you imagine, if you were writing down everything that you need to do on you write it in that format of Asaba Block, I need to blast So that block Well, sometimes it becomes a little bit redundant or it takes a little bit even longer, right? So what happens in practice is a lot of people just create the tasking, though in the form off, they start off with a verb, and then while they're trying to do so in the example that we covered before where we're talked about as a developer, I need to create the home page of the website so that the rest of the team can explore it instead of all that long sentence. What you could see is the same user story returning a shorter form, which is, for example, starting with a verb, create home page off the Web sites of the rest of the team, can explore it or just create homepage of the website. Right? And we all know that it would were working on these because the rest of the team wants to explore it right so you can do that and it's a way off. See it off simply fine. The user stories. And as long as everyone knows that, they're just still reflecting these are stories and that you're not writing down as I need to blast. So that block they understand the essence and the consequent used her story, and I think that's fine. You know, again, if you still want to go by the book and you want to write your stories asked on the role I need to the watt. So that and then the why that's fine, you know, That's why you can also do that, and I love scrum teams do that as well. The other thing is, normally when you create a user story, there's other things that you want to include in done, and one of that means this story point. The story points are essentially a measure of complexity of for the user story. And if you look at scrum practices, there's different ways in which you can assign user stories, though the one I recommend on this. I think the easiest one from my perspective, is that user user stories point scale off 13 and 51 being lo complexity. Three Being medium on five bean high complexity. So when you have a user story that you know, it's actually complex and requires a lot off work and a lot of time to finish, then you want to put that on. You want assigned to that user story five story points and the reason why we do these instruments because it allows us to plan ahead and see how much we're delivering over time . I will cover that when we look at some of the charts that you can use in scrum. Okay, but basically, when we're talking about user stories, I just wanted to know that there is a There is a fine four month and structure that you can use to write the user stories that the user stories come from business requirements that are there and kind of turned into tasks and off course, essentially an ideally you wanna have task that are delivering value to the to the end customer into the user. In practice, you're going to see that a lot of the test actually not necessarily do that, and I think that's OK. It's just for you to keep in mind. There's always and I always like to put things and give you real life examples in real world scenarios because, you know, we all know that practice very something's from theory, right about what I wanted to learn in the scores is both. I want to teach you the theory so you understand what the theory is behind it. But I also want to talk to you about practice and what happens in real life. And like I said before, what I see in real life all the time on what happens in real life all the time is that people ride the user stories in a shorter form because he's easier, faster and everyone already knows the structure of the user stories. So they just started with the verb at the very short sentence of whether try and then that that is the start of a very short sentence of whether trying to achieve so, for example, create blob planned blood test block, you know, developed bloody, signed these eso those. And then you add to those tasks user stories you add, the story points, then you including their also the acceptance criteria. So what are we going, Teoh? When are we going to consider this? Has done? When do we consider it finished? And that says so. Everyone's on the same page. Where's what is that word going? Teoh REVIEW When we review these user story before accepting it, there were before, considering it done. And then I guess last but not least, you want aside the user story to someone. So who is gonna have ownership over that user story? Who's gonna be working on that? Right? And that's part off your spring planning, right before you even started sporting in that spring planning session that week or before you're gonna be looking at those whose their stories and after you've assigned the level of complexity to each one of them. So the story points, then you're going. Teoh assigned someone to work on that that user story, and that's who is gonna own that in that sprint, that's it. I think that's pretty much all you need to know about user stories. And like I said before, there are different scales you know out there to for assigning story points, to use your stories, feel free to explore and Google them. And I can, of course, share links and give you some other examples in the course as resources. But I want to talk about that simple scale of 135 because that's what I have seen. That actually works really well in practice, and that's because it's also really simple and really agile. And remember at the court of the essence of any agile and scrum principles, you wanna have simplicity. So that's the one I recommend. And that's the one that I would encourage you to use in practice. The cabin board or the scrum Conven board is also just pretty much a visual representation off what the team is working on, so it allows anyone to actually see in real time where the team s is at, and these ensures that everyone is on the same page. It also ties, you know, when we're talking about transparency. Before that transparency everyone on the same page. Everyone clear on what they're working on. A broom clear on priorities and so forth. And it's gonna be, you know, like I said, visualized in a physical camera on board, which can be just, you know, a piece of cardboard with columns strong and, you know, posted notes. Or it can be just a digital version of the of the board using digital tools. And I'll provide examples for these for you to review hearing the course as well. And these party fact in particular the scrum artifact, is one of my favorite ones. I really love the scrum Cambon board or the convent border. The agile camber board. However, you want to call it that those three names are essentially the same thing, is just a board that allows us to see where we're at. So generally these board has four columns to dio doing que a and done, and sometimes I like to add 1/5 1 which had called parking lot or ideas. And this is also just something to manage expectations, something with the product owner or with stakeholders that might request something that we're really not going to be able to deliver where it really doesn't make sense for us to delivery in a particular sprint. We can just put it in the parking lot and then reassess it later on. Just gives them visibility that were actually capturing those ideas and not just discarding them because we don't agree with them. And so that helps us manage expectations with stakeholders, broke owner and so forth and is having those, you know, those columns there to do. Doing Qiwei and done allows us to all be on the same page and, you know, have a very good way off planning and structuring what we're working on. So the convent board is not something that a static. It's actually alive tool that you're constantly updating constantly working with as you're going through your sprint. Super powerful, super useful, beautiful. It's something that I really love, you know, and I used is a lot in my projects, even you and something when I'm when I'm not working in a scramble with us Crump team. I'm working on something else. A lot of times I actually use this particular tool even for other things, you know, it's a tool that you can actually use because it allows you to kind of see what people are working on and have a clear understanding Beashel understanding on where things are at in a particular point in time. So I love it's super useful, Super valuable. I hope you my straight on. And make sure you check that video and those tools I mentioned before about trail Oh, which you're gonna find super useful in practice. 25. Scrum Kanban Board example in Trello: Hey guys. So today I want to introduce you to my favorite scrum Cambon tool. That's trailer. What you're seeing on screen and trailer is a great tool and one of my favorite tools out there because it's free. It's also very powerful, and it's super easy to use, So trailer is a great way of managing your product back. Look, your sprint back look, and your sprint is a hole with your scrum can ban board you know your to do doing Qiwei Don parking lot and ideas. So one of the reasons I really love trailer is because you can have a limited number of users on limited projects in a single interface for free so you don't have to pay for using trail. Oh, they do have a paid option on a paid version, but the paid version just gives you a lot of extra adult functionality and pretty much, you know, gives you like things like changing the color of the background and stuff like that. But in my experience with the pre version, you have more than enough on the free version is great. That really wouldn't even pay for the paid version of this brother because I really haven't had ever They need to use the paid version that just because a free version is just really complete and this is great, you know, because not all of the free tools out there are like this. A lot of the free tools out there. They have constraints on the number of users, or they give you a free trial period, and then after the trial period, you have to pay for it or they'll give, you know you don't put constraints on. You know the number of projects you can manage in the tool and then just allow you to have a few free. And then if you if you exceed two or three, you have to pay and the same with the number of users. So none of that existing Trillo And for those that haven't seen trailer these a quick. You know, I'm just showing it to you right now on screen so you can have a sense for it. But basically it allows you to create tasks, and I put a lot off detailed information with each test, like you're seeing your on screen in this example. So, for example, pieces that ties that have does nothing to these people here he has. The labels were marketing. The sign websites probably attest, relate to marking this on a Web. Here's the task Web design, and here's a description off it. And, as you can see, you can out of attachments to trail. Oh, uh, toe Utrillo task. Or, you know, this is what we would using scrubbers user story. And you have a lot of other options here on the right on, you'll just get family rights with Dallas. You're working through them, but I just wanted to show you that his online it's also available on your apple app store on. If you're in an android on the Google play store and they up, it's also free, which is again great, because it means you can work collaboratively with your team members, not only from your home or from your Dexter poor, you know, left but also on your mobile device. And that's great. That's super super powerful, and it's definitely a great too afraid, so let's just jump right into it. Let me just log in and show you how I can provide a couple of examples about how we would use a scrum Cambon board in trailer or right? So after you, logging is what you're going to see on your Carrillo. The first time you log into trail, you're going to see these screen right here and on the left. It gives you some options you have here menu on the left hand side of the top, and also the right hand Sanders were hand side as well. You have a little bit more options, but let me just go right into it and just create, like, but the calling trailer aboard and for us aboard. Here, in these scram examples, we're talking about a project. I'm just gonna go create, create new board, and I'm gonna just put the title scrum project. Okay, so this is just gives you the option of putting here a background and private or public. I'm just gonna living in public and private story so that only members of the board can see it on make Ah edit. This public option allows anyone on the Internet to see it, even Google, but they wouldn't be able to make any changes to the board unless you granted them access to due to do so. So I'm just gonna live it in private. General, you're gonna probably be working on private projects. So let's carry on with private and then create board. All right? So basically, we're creating our scrum project can be on board. I'm gonna remain to rename this. You can rename this if you want to get the scrum project. Can Ben board right? Or maybe am just in general, rename this to Project Tex Wise it then scrum can been bored. All right, so, of course, this is the title. You can put whatever you want in there is just an example for you. So don't worry too much about that. I'm gonna put Renee and rename that. Okay, so I have now Project X scrum can been bored. So this is what you know trail allows you to do is add lists off which, in our case, is gonna be our combat board. Right. So, to create account your scrum conven board, I always suggest that you had the following headings in the following following columns. So just create a column that's called to do right to do All right, then this creator call him hearing you're creating basically dynamically right now are Scram. Combine board for product X Y set on doing another one called done. I'm gonna put Qiwei. Check this out. This is really cool about trailer. You can actually move. You're different columns from one place to another. Okay? Like you're seeing on screen, you just drag and drop, all right? And then also create another one here called parking lot slash ideas closes for the now. So this is just your activity feet and it tells you what's been done recently on by you. And of course, you have here on additional options as well. If you could come. Or so This is just all like config and settings and extra things that you cannot to your No , you're you're Can one board here, your scrum combined war here and trailer. But I'm gonna close it for clothes that for the time being, and so we have remember, you can scroll down here at the but the bottom as well to left and right. And also you can, as you have more things on the screen from top to bottom, you can also scroll from top to bottom and vice versa. But for now, but also create another one just school. It was called this product backlog. All right. And then I'm gonna move this to the left. You could create a separate board entirely for your product backlog, but in this example, I'm just gonna leave it like that for you for now. And I'm also gonna create another one a year called Sprint Backlog. All right? Okay, cool. So just keep in mind and remember that in the product backlog, we wanna pull put all the user stories off everything that we need to do in this project. Right? So in this product actually said, which is just an example, I'm gonna assume we're gonna go through this scenario as if we were actually creating an application. OK, so let's imagine, for example, that we're creating an application like Skype. OK, which is a chat application. But it also allows us to do video conferencing, texting, messaging on a lot of other cool things. Right. So this is just an example of k off course guys, but let's just, you know, go through it so it gives you an idea how you would do it. All right, So we talked about in the user story. And I'm just gonna ah, right. This here in the user story for months. So you remember it so as a right asked and then we have the role, For example, a project manager. I need to the what? What you need. So that why right? And why you needed Okay, Normal. These is the traditional format for you to write a user story. So, for example, as a project manager, I need to create a project budget so that management can approve the funding for this project. OK, that would be a user story, right? So they use their story like we talked before, Constant their requirements originally concerned the requirements of the project. But then it goes down, and that's better down into specific tasks off what needs to be accomplished to actually complete the project. Right? But I mentioned to you that in real life, a lot of times he gets to redundant to write this because it just gets repetitive. People already know that you're trying to convey basically something that needs to be done with a user story. So in practice, and I'm gonna right here rial word riel world example of user stories from what I see in practice and from what I do in practice in real life because I have, like I said before going through many different types of problems. And I know that, you know, using this foreman that is the official and traditional way of writing is their stories in agile and scrum is generally not very practical. So again, like always, guys we have something is, you know, going but by the book again. If you want to do this by the book, feel free to use these four, but with you use the stories. But in this example, I'm just gonna write them how I recommend my students and people to write user stories which is basically started with a burb, right, and then a very short one liner of what needs to be done right. And we want to minimize and shortened the tasks so they're not super long, just very concise, high level level tests on. I'm not going to write every every everything, everything, everything that you would have in a project. This is just a very quick tour. A very quick, short example of how you would set up your scrum can bond boarding trailer, which is what you're seeing on screen right now. Okay, so one of the things will need to do to create our Skype application is probably set up an interfaith rightto the sign product interface. That's one of our user stories, right? Andi, let's assume in this example that so you can click on it and then it will give you more options. You can add a description you can write comments on. This allows you, by the way, to interact with other people. If you wanted to include other people or you wanted to assign these user story to someone, you just kick on members and then assign it to whoever you wanted to assign it. I'm gonna sign it to myself right now because I've only added myself to these scrum Cambon board here on trailer. But unless you can see here on the left, my picture has been added here and that that's pretty cool because, you know, he's very visual, right? So right now I can see who's working on these particular user story. Well, nobody's working on it because it's not doing in on doing yet, and it's not part of the spring backlog either. So it's something we need to dio later on, but on the product. But look, we have all the different six players that are part of the project. But the other thing I wanted to show you is that if you wanted to include somebody else on the project, you can as well. So if you go here back and we go here to let me just scroll So going back to what we were saying before if you wanted to out someone here to your scram Cambon board, you would just click here If you see this at the top where you have my picture here, if you click here, will allow you to invite other people so they can work collaboratively with you in the scrum camera on board. I remember that they can also download the mobile app and work with it from the mobile app or from you know, a laptop Brodec stop! Doesn't matter if you toe windows of eyes are on. You know, an apple device. It would work on every type of devices long that they have a browser Internet O r. If they're using a mobile after the mole after they're using, well, mobile phone for that, and it's very simple. You just add their email address and then send the invitation and then they can join you here. And you can add them to the user stories and collaborate with them and so forth. Right? So let's just continue here. Designed product interface, create option to sand text messages. And we're writing all over user stories, right? Another one could be create option to initiate a phone call. We're talking about a nap that he seemed to Skype. Right, Um, now build functionality nationality to set up user profile right where people can upload their photo, etcetera. What else can we having? A Skype application payments, right? They know that Skype also accepts payments. So let's write it. This is an example, right? We're not building. Skype is just We're right. We're simulating. I said we were building approach similar to Skype, and we're creating all over user stories, and we now have our scrum camp on board here on their own on screen, and then we can work with it. So let's say that develop capability, capability to accept pay ments. Are they willing to do, of course, is testing. So testing quality or phone calls, for example, is one of our user stories probably is gonna be later than the truck in the project. In a Brokeback look, we want to write all over Easter stories, everything that we need to do. But keep in mind that at the beginning you will never have all the different user stories ever right, because he's a is alive document. It's on your your product. Backlog is he's a static, so you write as much as you can at the beginning, and then on later on, you continue adding, so testing, quality of phone. Let's leave that there. What else? I'm trying to think of everything that is part of Skype just because we're building a similar product. So option create option for screen sharing, right? There's something that I know existing in Skype. Um, what else? And of course some of these might be you might need into smaller break down into smaller user stories, but for now, I'm just keeping high level just to give you a quick example on, probably we need to start off by, uh, creating and forget about that. I just creating. I'm mark up off the product. The project manager probably means to one of the user stories for the project. Planetary is setting up the project budget. Right. So we will write all of these things, like create the product timeline, all of her user stories, everything that we need to do us part of the project on. Then after, let's say that in spring one, we're only gonna be working on the market. Right. So our spring back look, in this case, it's a the interface, the project budget and really the project timeline. That's it. Let's say this is, for example, or sprint one. Right? So these is how on a scrum can run board, actually looks like in real life. So as you're working through your spring, your start to through your spring, you say Okay, this is the spring back. Look, this is what we're gonna work. Be working on the sprint one, and then after you've defined that, you say Okay, so we're going to start off with moving all of this to our camping board. Right? So you know the product back? Look on the spring back looks kind of like you're planning session. You're planning phase. And like I said before, you can have these in a separate trailer board. But for now, I'm just keeping it here in this quick example for you. But basically all of these user stories we're going to to do because we're saying with this is all we need to do in our sprint, right on the sprint one. All of these user stories that we talked about before, where in our spring back Look on, we now move them to to do because we've started our spring till the spring back Look is what we had before we actually started the spring. And then when we actually start to spring, all of these moves to their to do because it is things we actually need to complete throughout the sprint on like we talked before. A spring can be up to a month, but normally and typically to two week long period. OK, so now let's say Marie, she already started working on the project interface. So we put it in doing on The other thing we want to do is to science story points, right, so you could assigned this story points here Okay. So you could just say three story points, right? And address a comment save. Okay, then we know this story is user story. Designed the party inter phrases, three story points because the medium complexity used her story. I could also add a checklist here if I wanted to. So let's say we call a checklist and we had it here. As part of the design of the problem interface, I need to think about the bottoms. Call to actions, help section logging, you know, whatever. Anything. This is just an example. Right. And you could have start taking this off. You're going through the spring tonight. You're actually completing that. And you could set a due date. You could have attachments to these, you could add. You know, watchers, if you wanted to, you could have comments, as you can see here, and you can, you know, at people can use, you know, smiley face emojis, and that you can see here Trailer gives you a lot of flexibility with how you want to use this. And of course, trailer wasn't designed Onley for scrum can, but board disease has ah wider application. But one of the many things you can use trail. Oh, he's for your scrum can been bored. And that's why I'm showing it to you. Because, like I said before, it's a completely free tool. And it's also my lover because of its simple easy, because how easy it is. You don't need any training for these, Really. You can just, you know, start playing with it and you'll realise that is very, very easy to use, like you're seeing on screen. But let let's continue here. So we have these right, Like showing me that there is one person watching it. There is one comment, and their Syria to four tasks that need to become sub tested need to be completed as part of these user story. In this way, we had our checklist and let's imagine here that we bought this to doing. Then you went for review for the manager and the manager is checking. This is their story and he said, Okay, check the timeline and happy with it. Then we will be to done right. Well, we to done okay so effectively now are to do doing Curie and under what we would consider our scrum camber on board and let's say these one is in Q A. Onda. We progress a little bit further than the spring. So this is what it would look like, right? So you have difference your user stories in different columns of your scrum convent board. I'm just imagine for a second that you have here a bunch of other you know, user stories and multiple people working on it. The beauty of this is it allows you to see everything that everyone is working on, you know, at a glance, you know, very in a very visual fashion on in a very quick way, you can see what people are doing on it allows you to control and monitor progress throughout your sprint. And this is why I really like trail on this way. I definitely recommend you guys give it a go when you get a chance. It's free on bond. You'll love it. Check this out as well. So you see this show many option. There is also here. Ah, option called Field Two cards right, which are in this case are user stories. So I could say filter by the user stories, which would be like tasks. Right? The user stories designed to Mauricio. And then it will show me just what Maurice he was working on, as you can see, So it's pretty good. And you could put colors right so we can put here, You know, let's say this is part off sprint one. I'm gonna put yellow. So this is filtering, by the way, which is why the disappearing like this. But I'm going to remove the field. So I guess, and then just go back here and then here I could have a label to it and say Sprint one sprint one and we can say its color yellow. Okay, So as you can see now, it has easy local or here telling indicating that this part of sprint one So there is one of the many options you have with trailer and you can see here that the field three still on so I could go to the field. They're here and say, Okay, I just want to see everything, and I just want to see the test. They're a part of spring one, so we'll feel trying to show me. And so this is one thing that you might find you find useful as well using this filter. Okay, guys, this is all I wanted to show you real quickly. And then it's a really quick example of how you could use trailer for your scrum. Come Been bored and I just had it a couple off, you know, user stories here to our first sprint. But as you're progressing off course, it would start becoming its start seeing more and more user stories. And of course, you would assign it to more people and more people working with you on the project. 26. A Real Life Example of an Agile Kanban Board: Hey, guys. Next I'm gonna show you a really life example, often agile, can been board for one of my projects, and this is a really life project that I worked on a couple of months ago. In this example, you're going to see that we had each team member with their own set off user stories. So we had the work in progress where we called in the product in the work in progress, which is basically the same less doing when we doing agile board and we create a column called Doing in this case, we called it a work in progress, and then we had to done at the end of the campaign board, which is something that you also have so generally when you create a Cambon board, you have that to do doing. Sometimes you have Q A and then done where you have the cure or not. It's optional. It's up to us, a team. Sometimes some agile projects would just or some agile teams would just do it. As part of their user story, performed the Q A with theme the user story, and then when they complete the user story, they would move into the done. So in this case because we're working on a project that was a huge massive project and because it was so big and it had so many different streams of work had to set up, the agile can be on board a little bit different than what you normally would. But the beauty of this is I can show you how you can adapt Adua Cameron board to your real life scenarios. So, like I've said many times before, Agile is very flexible. You don't have to play everything by the book. You have to learn and take what is the best that you can find and adopted and adjust it to your real life project or scenario in our particular case, like you're going to see in a moment because our back look was so big and we had so many things in it to do, We actually separated that in our trail. Oh, in a separate board toe are work in progress and our completion. And even when we were completing the work, we would move the sprints toe a separate list just because we have so many springs we were working on right So we were working on monthly sprints in this case, and we did that just to make it easier for us as a team to control the timing and the work that we were doing. So basically, we set up each sprint exactly asper the calendar month off each month. So basically, we're talking about four weeks prints, right? And in our case in this particular project, that made a lot more sense for us because we're working on huge initiatives and we needed a little bit more time to complete her are sprints. As you already know, you don't have to do for weeks prints. Generally, sprints are two weeks, but some agile teams 23 or four. It's entirely after the agile team and to their particular scenario to decide which Sprint duration works best for them. Like I said in our example, we chose four weeks because we're working a massive, massive project over multiple sprints, multiple streams of work, multiple stakeholders and different areas of the business. So these particular adaptation of the camera on board to our particular business need made a lot of sense for us, and it worked quite well. As you'll see in the example, we had all the user stories each team member was working on. We had our Donner completed spring least of user stories, and we had a separate backlog and a separate list off everything that we had completed for all for previous sprints. So it worked really well for us because we could rest reference of work back really easily . We could also assign story points. We could also look at our velocity and how we're progressing on this also helped us when we're doing our retrospectives and looking at what we have accomplished and how we have done in that particular spring. So without further ado, let me take you right now to the example we just discussed and you'll be able to identify and see their riel life examples off what we've learned so far in the cores. I hope you enjoy it, and I hope you make the best of it. Cheers, way 27. Velocity and the Burndown chart: So the concept of velocity is about how much you are delivering over a sprint. And we talked about this in terms off story point. So have any story points? Did the team deliver over a sprint? Okay, so that's essentially what the velocity is. So say, for example, in use your sprinkler. Spring five, you have five user stories with different story points assigned to them, and they add up to 10 story points in total. And let's assume in this scenario that you actually completed all of the user stories. And after you finish your sprint right and somebody ask you So what was your philosophy, right. Your velocity off these was 10 right? Because we said you were working on five different stories but that the some of the story points assigned toe all of them out of 10 right, because you actually finished everything. Then we can say, Well, they actually delivered This scrum team actually delivered Stan story points after finishing this sprint, and that is what we call the velocity. Okay. And now you're thinking about well, what happens when I have multiples sprints? But what is the velocity if I've actually going through the five or eight different sprints . Well, the velocity is the average velocity off the individual velocity off each sprint. Let me repeat that. So it makes sense to you. And so it's completely clear if you're asking about the individual velocity off a particular sprint, it is the number of users story points, story points delivered over that sprint. If you have multiple springs on your trying to calculate the velocity off multiple springs , it is the average off the individual velocities off each sprint. All right, that's it is very easy, very simple. And the best way to understand this is by looking at a chart, and I'll provide an example so that you can see what a velocity chart looks right here as well. But what is the importance of these and why do we want to measure velocity? Well, basically, because this helps us in our planning process, basically also because this helps us to track performance and effectiveness, right? So if we're planning to deliver, let's say 10 story points in the spring time, we actually delivered eight, then well, we should reflect on that in retrospect, even see, Where did we go wrong? They we try to do too much in that sprained or you know what I mean? Or do we run out of time, or do we run into roadblocks or issues and we weren't able to resolve them in time, so something didn't allow us to meet our targets. And generally what happens? He's at the beginning off scrum projects. You're working in your scrum projects. What happens? He's that what it sees that a lot of teams actually over over estimate and kind of like think that they're gonna be able to deliver more than they can really deliver. And that's very normal. That's OK, but there's nothing wrong with that. So you'll have a velocity initially that is below what you have projected on do. You might find that there's variation when you look at a graph because or regional, you were trying to do too much and you you're just starting to understand what you can actually really deliver in reality. So over time, what I'm trying to say is that over time, scrum teams will become a lot better in their estimating a lot of bettering their delivery on a lot better off course in their velocity so you'll see that the graph starts to become more and more stable over time as you're seeing that there become more accurate in there in their planning process and what they're going to actually deliver. Alright, guys. So the burn down chart is one of the scrum artifact that allows us to see the amount of work remaining and how much progress we're making as we're progressing through our sprints . And it's really easy to understand. And really simple graph like the one you're seen on screen in which we have at the Y axis a number of story points remaining. So the told sports story points remaining in any point in time and on the X axis is the sprints off course. If you think about this carefully, the number of story points that you've delivered between sprints can be seen from this graph. When you subtract, you do the Delta between Sprint. So, for example, if I looked at Sprint one and two in this particular example, I went from 41 story points to 32. That means that between spring one and spring to, I actually delivered nine story points and that as we talked about before is what we call velocity. So it's crumb. The number of story points that you deliver between sprints is velocity. When you have more than one spring, well, we just calculate the average off the individual velocities between Sprint. Right? And that's how we get our overall project velocity. But again, in this very simple example, we're just looking at, you know, the sprint between sprint one and spring to So after you finish sprint one, you've basically delivered nine story points, and I can see that because of the Delta between Spring two and Sprint wants, which is nine story points against Super easy to understand, super simple. And it just allows you to check in a very quick way in any point in time. How much work is remaining before you actually complete the project. All right, I hope that's very clear and easy in front to understand for all of you as you're seeing these on screen, and it allows you to understand this concept, which comes up often when you're thinking on working with Scrum, and you might hear people talk about the burn down chart and the reason why it's called Burned Down chart is because it's burning down. It's kind of like showing a visual representation on how you're burning down through the work that you have to do. That's where the whole concept comes from. Alright, guys. See you on the next one. Cheers. 28. The Product Backlog and the Sprint Backlog: We've talked about the product back. Look multiple times before. But let's now put all of that together one page or summarizing and consolidated. Okay, so the Brokeback love is essentially a list of everything that needs to be done in the project. Right? But this list is basically composed off user stories, all of your user stories on there, you know, putting together went into what we call the product backlog. The thing here you need to take into account these, that you generally want to start a program before you start the project. Right? So before what we call before your first spring, what we call in scram your spring zero. You want to make sure you've already met with your team and documented all the possible user stories that you can think off. But of course, you can't predict the future, and you might not. You might not know exactly everything that has to be accounted or taking to account for in your project. So basically what you want to do is capture as much as you can and just keep in mind that this is a living document. It's not static, and it's something that you can update later on if required. It's something that is dynamic live and you know you can refine. We talked about before those back local product backlog grooming sessions that this is what you would do. You would go over your product back, look and then see Okay, you know, we have 100 items. Are they still applicable? Yes, and you keep them. Some of them are not applicable any longer. You delete them, you remove them right? And this is the exercise. And this is what you want to have in your product that love generally. What I recommend teams is that they put the top priority items in there. The top priority user stories at the top of the product backlog on then from south, from things that are from the top party to the least priority, that order. But even if you didn't have it organized like that, it's not that it's an issue, is just that it's best practice. So that's pretty it That's pretty much it. You know, there's not really too much to say about the probe back. Look outside from what I will recovered, and aside from what you're already seeing on screen in this video. It's really simple. And again, it's all about having your user stories documented in at least somewhere. Now that doesn't need to be. You know, it doesn't need to be in trail org or like I said before, there are other tools out there. If you're not using something, did you tell about like a physical board? Then you can put that, you know, post its and put all of your user stories in just a whiteboard or whatever you want to put it on. And it's called it the product. Bad luck, and that's it. That's all you need to do in this part. When you're talking about working with brother backlogs, the sprint back look is basically a subset of user stories that you've taken from the product backlog and assigned to a specific sprint. That's it. You know. It's a group of these are stories that you've taken from the Brokeback Look on again, assigned to specific sprint, that is your sprint back look. So everything you're gonna be delivering in a particular sprint, we would call the Spree sprint back. Look, now, here's the key difference, right? The product backlog is owned By who? That's right by the product owner. The product owner owns the Brokeback look right he owns when you're trying to deliver us a hole and he owns the order of priorities and he tells you what are his priorities or hair priorities from their perspective, right in the spring backlog that is actually owned by the delivery team by the scrum team. You guys have ownership of the spring back, love, and you can, you know, off course, Prioritize that as you're working through your spring. So you might say, I'm gonna We're gonna focus on these user story in the 1st 2 days of the spring and then these subset of user stories in the last three days and so forth. But again, normally you want to sign those user stories to someone in the team is gonna take ownership on responsibility for making sure that that is delivered by the end of that sprint 29. Demo of a non IT Agile project - Part 1: Hey, guys. So in these next part of the course, I want to show you are really life example off one of my agile projects where I created a podcast in less than five minutes. That's right. In less than five minutes, I was able to create a podcast using agile principles. And what I did was basically what we would call in agile. If you remember, we talked about the concept of M. V P. Minimum viable product. And I'm gonna show you how I created a podcast in this next part of the course on You're going to see it really life, because this is a really world real life example. And it even has a timer. So you can see that I did this in less than five minutes. And this is the beauty of a John. This is the beauty of the concept off M v. P, in which you can create something of first iteration in your sprints and Daniel in iterated and enhancing over time like we do in agile. Right? So we thought further ado. Let me just show you real quickly. And I have this already opened on another tab. This is the learn about podcast and these learn about podcast is the podcast that I created in less than five minutes, and I wanted to show this is, ah, riel life example of an agile project because I often get get asked about examples off non I t projects, and this is a perfect example of it. This is a non ICTY project. It is basically a creative project in which I created a podcast in less than five minutes, and that's beautiful. I love it because it's such a great example off how, in the first spring I took the focus off doing an EVP, just getting everything ready to launch the Parkers without even adding any outer to it. So I just launch if you can believe that apartment without any audio on it. That's how it launched it initially. That was the concept of the M V P minimum viable product. So the first print I was just solely focused on launching and getting it out there. You know, putting a title, putting an image, describing where the part cause was gonna be about making really simple super in Torrey, super intuitive, super user friendly and right after I launched it on by then added audio on the second and third Springs. That's what I was focused on, right guys see in the next one. 30. Demo of a non IT Agile project - Part 2: and 31. Increment and the Definition of Done: increments in scrum are basically deliverables. So it's basically what you've accomplished after a sprint that where we called an increment in the scrum world. In essence, it's a step towards a vision, a goal or you know what you're trying to accomplish, right? It's progress, right? That is what a skinny what an increment is is. You're actually delivered something and that is the deliverable off the sprint. What we call in scrum increments. Now we call them increments because they're not the end solution, right? But they are a solution and it's something that can be used to build on top, off or upon on for future generations or future sprints. So I think that considering something done finished a complete is very logical. You know, it's something that most people know and naturally do, right? But what is it? The frenzied scrum? The difference is that it's crumb only consider something has done when it's actually met the acceptance criteria that we've defined for that particular user story. Right? So off course remember that we're delivering in in our scrum process are increments that comets are some off all of those user stories, right? So for us to consider something done or complete. We need to make sure that those user stories have actually met our acceptance grant interior that we as a team we'd on before we even got started. So those are the key things that you need to take into account when you're thinking about when to consider something done or what we call Dun Dun in Scrum, which is making sure that it's actually met those variables or those requirements or those basically, in essence, that that has acceptance criteria that we defined now off course, This will vary by team because what each team and considers done will be different, right? It will depend on the acceptance criteria that each team define on. There's no hard rule around that. There's no specific rule that is gonna tell you what is the acceptance criteria. It's gonna be their friend for each team, and it's probably gonna be different for each project as well. So in some cases it might just be Yep, you know, somebody confirmed that that that was complete, so we acceptance criteria could be a simple of someone saying Okay, as a team, we're gonna agree that the person working on that particularities. Her story he's gonna market complete when he's 100% sure that he finished everything he needed to do related to that user story. He could be a simple as that. Or it could be somebody. We're gonna consider it done after somebody has actually tested what that person said they were going to do, or we've actually verified that they completed what they were going to do, you know, as they actually said, they were going to do it. So again it varies. It might be a checklist, and you might have a checklist off things you want to review as part of your acceptance criteria. There's no hard rule on this again, guys. The main thing is, keep it simple and make sure everyone's on the same page on what you've agreed on to consider something done before you move it in your scrum. Campbell board to that column To that, you know, of course, field where it's marked is done 32. MVP and things that help Scrum Teams: Let's talk about the M V p or the minimum viable product in scrum. And when we're talking about the M v P, we're thinking about the must haves. Forget about all the nice to haves. Forget about all luxuries. Are all things that you think would be lead and think on Leo. But it's really, really required. What is really, really needed. What is the bare bare minimum you can deliver that will still meet and the river a satisfactory outcome, right? And going back to the example off. You know the skateboard on the car, which we covered before. Well, remember how escape board allows you to go from point A to point B. That is the M V P. Right? So the M V P is that skateboard because it's probably the most simplistic thing you could build to still allow you to get from point A to point B so it meets their requirements right, because it allows you to go from point A to point B, which B, which is the minimum requirement that you had, which is the minimum thing you are trying to accomplish, but it allows you to do in a very simple fashion. It allows you to deliver, you know, quickly and often, and either rate and improved over time. That is what you need to do when you're thinking about the minimum buyable product. And that should be the focus off any scrum team you don't wanna, you know, build something with all the bells and whistles are over, engineer it or deliver something that nobody's actually requested, right? You just need to think about those must haves. And those must have are what we call if you took out all the nice to have all those extra things and you just left the must haves when you're thinking about your user stories and what you need to deliver. That is what we would consider in scrum your M V p. Your minimum viable product. Now there's a set of things that, of course, can help scrum teams be more successful. I'm gonna talk about some of them in these part of the course. One of them he's co location. Ideally, you want to have people that are working on a scrum project. Sitting together on this becomes really important when you're thinking about scrum rituals such as the day is Crum, right? Or the daily standard? Because they're going to be talking to each other on a daily basis for a very short period of time. So they're sitting together. Those interactions are gonna be made a lot easier and they're gonna be a lot better. So make sure that as much as possible, you have people working on projects that are using a scrum methodology that make sure that they're sitting together in the same room or in the same area. That will help a lot. Trust me, I've seen this in practice and I've seen the difference it can make when you're working on your projects again. Those teams are also going to be working with a lot of tools and different rituals that we covered before. But things that can help is definitely online collaboration. So, you know, using things like Chad Chad, clients who chatting as required and you know, having your convent board did you tell? He's also helpful in case someone is away. And making sure that the team is empowered and able to make decisions as a need is also a key component to the scrum team success so off course and by these. I mean, you need to make sure that the team that is working on these has the full support from management. You know, there's a nim principal agreement on the work that's going going to be done on allows the team to work, you know, with a bit off independence and with a focus on execution knowing that they have, you know, that support from management to make those decisions when they when they come up. And, of course, he also have us. You know, the role of the owner there to help you. So you don't have to, ofcourse, have all of those hard conversations with management. If something changes, that's why you have your throat owner. Therefore, he should he or she should be able to help you reach. You know, those conversations are liaise not only with senior management about with key stakeholders , so definitely having you know all of these in place and having a really good product owner assigned to your project, he's gonna help a lot and just making sure you are also accepting of the fact that there's gonna be volatility and changes in requirements and there's gonna be unpredictable challenges but that you're gonna be using retrospectives and your eternity process, and you're continues improvement to ensure that you overcome those challenges you know, and get and get to your goals and reach your objectives that these things that I'm coloring here are things that I've always found helpful. And I've always found help. You know, scrum teams deliver their projects on time and on budget and work better together, and just it works a lot better for them. The other thing. I also want to highlight the importance offs, training and coaching, right, So make sure that your team has actually gone through training. If they haven't, I definitely encourage Ito either recommend this course to them or buy it for them if you must or gifted to them or get get the company or the baseness to recommend this to the rest of the team, because that will allow you to all be, you know, working on a common ground with common knowledge, common terms and our general understanding off. What's Grammys all about? So those things, for all my perspective, are the things I would say that actually helped scrum teams on the ground and working through their projects on. We just talked about two key ones which were having good good leadership. So not just, of course, a really good product owner, but also, of course, a good scrum master. But making sure also that everyone has good training. Andi Good understanding off scrum which comes, of course, from education. Such a Z scores. 33. Scrum FAQs The Acronym: Hey guys. So let's talk about the frequently asked questions or f excuse about Scrum and let's start with one of my favorite ones what the scrum stand for. What is the acronym off Scrum? And this question which often himself comes from a misconception that people have. The scrum is an acronym when in reality it's not okay, so Scrum is not an acronym and it doesn't stand for anything in particular. It's a just a word that derives and comes from the sport off rugby, and if you saw in another part of the course when we looked at this history of scrum, we already discussed where it came from. That is actually a playing rugby, and they then became used in agile. And these nowadays used to describe one of the many agile methodologies. So scrum, like I said before, is not an acronym. Don't think of it as an acronym is just a word that came from rugby and that is now used to describe this particular agile methodology. And we've been talking about scrambling throughout the whole course, so you already know what scrum peas and what it stands for. But like I said before It's quite frequent and quite common to see people thinking this crime it's an acronym and that it's actually award that stands for something when in reality it's not. It's just award that has meaning, like we've already discussed before. Now another question that comes up all the time is what is the difference between agile and scrum? And this also comes from another misconception, and that's that They are two different things. In reality they are, but at the same time they're not let me clarify about. 34. Scrum FAQs Agile vs Scrum: Okay, so another question that comes up all the time when you're talking about scrum ease what is the difference between scrum and agile and are they the same thing or are they different things? So let me just start by clarifying and saying that Scrum is one of the many agile methodologies. But actually it's the most popular and widely used off all agile methodologies. And for that reason, when people are talking about agile most of the time, like 90% of the time, they're actually referring to scrum. It's just a lot of times they're not familiar with the term terms Crumb or they're not even aware that there are other agile methodologies. So when they're thinking about agile a lot of times people are talking about scrum. They just don't realize they're talking about scrum. So like I said before, Scrum is one of the many agile methodologies. But it's the most popular and widely used off all agile methodologies. And here's another question that comes up as well, which is why it's crown so popular, and why is it more popular than other actual mythologies? And the reason is quite simple. Actually, Scrum is very popular because it's very simple. It's very easy to use, is easier to understand, is lean on. Documentation is lean on processes, is lean on governance, So scrum has become the facto, agile methodology used worldwide and people love it. You know, people love it because it's very simple and easy to use and easy to understand. Like you saw in the course. There's nothing mysterious or nothing really complex. About Scrum is Justin when people have never started it or they've never heard of it before . They start hearing about some of the terms used in scrum like user stories, retrospectives and so on. Well, something they get a bit scared or they're just not unsure what people are talking about. But once they actually get into something or and actually start studying like a course like this one, or you know, they attend the conference or whatever, they realize that scrum is actually not complex and not easy. Not hard, actually. Sorry. And it's actually easy and easy to understand, easy to use, easy to implement and that it delivers value quickly, often on that is very customer centric 35. The Daily Scrum and the Sprint: Now let's talk about the daily scrum or, as many people call them, the daily stand up. This is a daily, very short, very focused meeting in which the teammates, to ensure they are in sync on on track on what they're working on. It shouldn't be any longer than 50 minutes, ideally less if possible. And basically you're trying to answer three questions in this exercise. And indeed in these daily stand up or Davis Crump. Why did you do yesterday? What are you working on today on any issues or impediments? And this is not just a question that is thrown out there, but what you do is you kind of go around the table, although the whole consequently quite so called daily stand up for days. Comey's because generally people are standing up. So ideally, you're not even sitting down. You look at your Cambon board and you're standing up together and there and talking through these three questions. Each team member will go through those three questions right on this daily stand up on their list. Crumb. He's for this crime team. So you don't wanna involving these these meeting your owner. You don't want to involve you know any outsiders. Ideally, you just want to have your scrum team and the scrum master going through these exercise on a daily basis. It creates their seaplane, but it also helps them stay in sync. I don't track and it makes sure that the team's remains focused, you know, has a really good sense of urgency. And, you know, if something is not working or you something needs to be changed or there's a road book or an impediment where the scrum master is gonna help resolve that, you know, I live right there on the spot really quickly before right after the meeting like that, he's not gonna wait until or she's not gonna wait until the end of the sprint to start working on that we're gonna solve that, you know, on the same day is both possible or the next day when I'll be really quick. Remember that springs are a set time books period of time, and we don't have a lot of time than to wait until things get towards the end to result them. And that's why these daily stand up. This daily scrum is so important. Sometimes I get asked about what is a good time of the day to plan your daily scrum. And it really depends, you know, like there is not a hard rule on around these in terms of the l has to be at the beginning of the day at the end of the day, in the middle of the day or at nine AM 10 AM or whatever, Not really, you know. But generally I do recommend that teams have planned their daily scrum early in the morning . That way doesn't break the working day, you know, as a working that they don't lose the momentum. And that way, you know, is there is there just like fresh in the morning. And ah, you're the meeting to make sure they're still on the same page on track and working on what it should be working on. They have a clear sense of their priorities. But again, you know, this meeting is not is not meant to result. You're not meant to be resolving things right there on the meeting. It's more an informational meeting meeting, and it's meant to be a very short meaning, because if you start trying to resolve where if you spend too much discussing a particular topping. That meeting? Well, you're definitely gonna blow out of the 15 minutes, and that's something you shouldn't be doing. You should avoid that because the daily scrum it's not a planning session, right? He's not a retrospective, right is just a very short, daily ritual in which you get to get with your team to go over the streets. Question that we talked about. Why did you go yesterday? What are you working on today and any issues or impediments? Right. And sometimes you might go to a team member. He talked about what he did yesterday, what he's working on today, and he said, I don't have any impediments. Great, even better. Well, let's move on to the next person, right? Keep it short, keep it quick, keep it rolling and give it simple. Now you pretty much already know what Sprint is, but let's do a little bit of a recap on the Sprint. Aspirin is a time books period of time off one month or less, typically two weeks. The team works to deliver an increment or a ship, herbal product or service during that period of time. During that sprint and things that you should take into account while you're working in your sprints. Is that once you said undefined what you're working on spring. Ideally, you don't want to increase or degrees while it's already happening. So you don't want to have changes during the spring per set on. Don't get me wrong. You already know that in scrum, we actually embrace and accept changes. The thing here is that as you're going through your sprints, you want out embrace and look at those changes for the next point. Right, because if you're making changes to Brother Sprint and that's probably not going to allow you to deliver on, remember guys. We're talking about a really short time frame to deliver something right. It's pretty is a very short time frame, ivory, short set period of time to deliver something. Okay, and sometimes I get the question about springs, whether you should be bearing the length of your sprint. The answer is no idea what you want to keep that a set time box beautif time throughout the entire life cycle of the product. So if you have two weeks for your sprints and keep going, always two weeks. Two weeks, two weeks, two weeks that those are your sprints. It should shouldn't be. One week, two weeks in our week, one week, another spring, three weeks and so forth. Now what I do think is, and this is off course at the core. In essence, off agile is if you're let's say you initially started with two aspirins on you. Just quickly realize that that's too short for you, that you can't really deliver much into a week. And that is not working well for your team. Well, no point in keeping your sprints two weeks. Then don't don't keep them two weeks. You change it to three weeks and then just leave it in three weeks and keep working with three weeks, right? Because, like we said before, the whole purpose off scrum is that your continuously reflecting for improvement? So if something's not working well, well, don't keep doing it. And like I said before, even before you start with your sprints, you were going to have your spring planning session, right? And as you're doing are going through this brain, you know, let's say it's a two week spring, right? That's that You're the spring has a two week period of time books, then those things that are part of that spring are things like the daily scrum. So you're gonna be every day throughout those two weeks. Every day you're gonna be meeting with your team for a 15 minute period of time every day. Very short, very concise, very focused over the questions that we took before and during the spring. You're also gonna be doing your development. You're gonna be working on the delivery of what you're doing on. Then after the sprint, you're gonna have your sprint retrospectives right where you don't reflect for improvement and you might have a spring review session as well. The other really good thing about Sprint's is that because it's such a short pier of off time on because you're working on a particular set of user stories during that period of time right there in your sprint. Well, the limits, your exposure to risk and cost right, because you're not taking too many risks when you're working on a particular subset off user stories and you're not going to be spending a lot off money when you're working on something for just two weeks, right? So that's one of the other things way management and businesses like Scrum because it limits the exposure to risk in cost. It minimizes them. So that helps. That helps off course it does. It helps because you're limiting, you know, things that can potentially go wrong. You're limiting, you know, cost expenses. And you're actually making sure that you're delivering quickly and you're labouring often. So that's one of those great advantages of offsprings. As a concept like we saw before, I like we already covered. 36. Sprint review meeting and restrospectives: So let's talk now about the Sprint Review meeting. And this is something that occurs again after you finish a sprint. And it's a very informal meeting off up to four hours for a one month sprint in which are basically going to review. Ana says the results off the previous print right and why you're doing this is to take that and bring that as input into your next sprint, right? And in the spring review sessions, you're gonna be looking at your velocity, your burned down charge and other metrics to see how you guys did. As a team, you're gonna also update the product back looking. So if you need to include more user stories if you need to remove some or if something's no longer applicable, you know this is that session on this Is there re trolling, which we're gonna be doing that you're also going to be reviewing during your spring review meeting, your project timeline, your budget and so forth. So it's pretty much kind of like a moment and a period of time in which you're assessing. You know what was accomplishing the previous sprint and putting that all together a scene put for the next print planning session and also for your retrospective was course because you're gonna be reflecting off on all of these things. Even retrospective session, which is like I've said before, are beautified lessons learned exercise. Think of retrospectives a bit of as a lesson learned exercise in which your meeting with your scrum team to go over what went well, what didn't What can we do differently next time? So it's an exercise for continuous improvement. And like anything else in scrum, it's something that you're doing continuously. So not just at the end of the project, like in traditional product management, where people meet for these lessons learned post implementation reviews. But you're doing these after every sprint, and this is input for your next print because you can then take into account those lessons learned and make sure you make adjustments, improvements or whatever you need to do to ensure you made delivery and your targets on your goals in the next spring. Okay, that's it. That's pretty much all you need to know about retrospectives and these again is also one off my favorite exercises in scrum because it makes the team reflect on what happened in the last print on, you know again how they can better prepare for the next sprint. So it's a very collaborative, and I and I think you make sure you try to make this as informal as possible. So people feel really comfortable speaking up, and you want to make sure you capture all of that you know, generally in a board or in a war document. Or if you want to use your trailer or whatever you want to capture and make sure you're capturing the answers to these questions on do it up because as a round table, So start going through these questions, you put them on the board on a white board. What went well, what didn't what can we do differently and then just do a beautiful roundtable exercise where everyone within the team contributes from their perspective to each of those three questions 37. Gitlab Demo: Hey guys. So I wanted to show you another real life, real world example of how we're using Scrum and Agile Lee One of our projects. And this is a really world example. And I'm gonna showcase this example with a different tool than Trillo. Just a showcase. And to show you that there are a lot of other tools out there which you can use to managers , crumb projects or your agile projects. Now, today we're gonna be going through good lab, which is one of those really good tools out there to manage your products. And one of the really cool things that I love about good lab, in case you haven't heard of it, is that you can have unlimited projects and limited people. It's all in the cloud and it's free. So it's really, really good, I guess if we're comparing it to something like Trail Oh, it's a lot more robust. I guess a little bit has a lot of extra features that you wouldn't find on trail. Oh, so I wouldn't say that one is better than the other. They're just different, and I think that sometimes you just need to play a bit with different tools to see what were you really like and what you prefer and what your team prepares, right? So I'm not one of those guys that Onley uses a particular tool all the time. Ashley, like trying and exploring different APs and seeing what is out there and seeing what I can continue to use my different projects. And that's why sometimes I'm using on your seeming using different tools with different teams on different scrum projects or the different agile projects now on these one. Like I said, good Lab is one of those tools you can use, and I'll show you a real world example in a moment. But let's just quickly go through the homepage of Good Lab, and you can get to give love, give love that calm. If you go to get up the come here on your browser, it automatically when he goes to get love, that comment automatically goes to about so don't worry about this about part here. Just enter. Get lab dot com on your browser and you'll get here and then you can register here for a free account, you know, like I said before, there's nothing really that you need to do special about it and just enter your full name, user name, email, address, your password or you can signing with Google Twitter, get Hub Big Bucker Salesforce and create your account. Now, as you can see here, there's a couple of things that I mentioned before. But like I said, one of my favorite things about good love is just summarize here, given up offers free, unlimited private repositories and unlimited collaboration. So, like I said, that means that you can work on different projects and I'm just gonna go back to the home patients so we stay here. But you can use this kid left tool on different projects, and it's pretty cool. I know it sounds like it's more off a development tool, like a tool for developers on it. I guess, in a way, it was designed originally for developers. But currently give up is being used by people that are not necessarily in the I t. Industry or not that are not even developers like myself. You know, I'm a project manager. Us. You'll know I'm not a developer. I'm not a technical guy, but I'm using this tool. I can use it because it's very simple. It's free, is intuitive and there's a video here and I'm not gonna take you through it right now. You can click on it and then you'll see a video on YouTube about what kid loved us, but just real quickly. I wanted to show you a couple of other things. It's used by more than 100,000 companies worldwide, and as you can see, some of the big guys are using Good lap. So the NASA you know, Citrix, Buyer Sony, the U. S, Air Force Erickson. And so some of those really big companies out there are using Goldman Sachs are using Get Lab. And if you are familiar with get Hub, which was acquired a few months or years ago by Microsoft, is very similar to get help, I guess. But this is a different, I guess, Open source product, which is called kid Lab. And as you can see here in these little beat, I'm just gonna go here. It shows a little bit of the different things you can do and get left so you can manage your projects. You can plant them, you can create, and this is about coding if you're using coding. And like I said before, you don't really have to use this. If you're not coding, you can verify. You can pack it your code if you're coding again. But some of these things if you're not coding or you're working on I t projects like I said , they're not mandatory there just features that are there for you to use if you need to use them, but you don't have to use them. So, of course, like I said, you don't need to be a developer in 19 working on I t project to use Kid Lab. But if you're a developer, you're gonna love Kid LA because he computes all those really cool things that you need to do to manage your projects and your user stories. And you can been wort etcetera. But you're also gonna be able to, you know, do your coding stuff on all those are technical things that you guys do for those are developers, and you would know more about that than me. But then here you know, security how to release up. If you're working in the software product, how to configure monitor, which are. That's reports stuff like that defend. So this doesn't have automatically. At least not that I have seen the burn down chart, you know, velocity charge. But that's really easy to use and creating Excel and included a template for the things, of course, if you need to download and create, you know, velocity charred or burned down chart. Having said that, a lot of teams don't use those grass, and they might be just using their camera on board. He really depends on how you want on my not your project. It's not a hard rule in a lot of the things that we do inscribed, agile. It's up to you, really. Whether you want to use those graphs off course, I do recommend you using them. And that's what every into the template in the course, which you can download. It's an Excel file template. You just enter your data and automatically draw those those grass for you. Now I'm pretty sure that some point in Time Gate Levee's gonna have that. They don't have it right now, but I'm pretty sure that at some point in time they're going to develop that, so stay tuned for that you know. And I'm sure at some point when it comes up, you'll just see it there. I'm just gonna go a little bit further there. So yes, you can work concurrently so multiple people can be working concurrently. Alright, guys. So, like I was saying, you know, not sure there's a lot of things you can do with Give love, Bond, you already. So we already walked through all of these and give love as even a lot love more than what you're seeing right now. Here on screen, the young manage plan create very five package secure release, configure, monitor and defend. There's a lot of other things coming up, as you can see below here on the road map on day even mention other products that, you know, people working on I t projects normally use, which could be replaced by getting up by. Like I said before, it doesn't mean you have to be working on I t project or you don't need to be a developer yourself to be able to use gid le as you. So before you know, if you're using did hobby If you're using Trillo asana if you're using Jezeera if you're using C A. You know, that doesn't matter what you're using. Most of the things that you're finding a lot of other project management products and a lot of other agile and scrum management products you can find on getting up. Which is why I wanted to show you this example today. Andi, you know, they're one of the cool things about gay lobby is that it's a very active community on the releasing new, you know, new features new things every month. So they're working in a very agile and a charity where which is pretty cool. And I'm not gonna go through everything everything that you're gonna find here, but just real quickly, You know, of course, at the bottom, you can find more information about them from same at the top. They do offer some additional extra features in. If you go to their pricing, you can see that they have a little other extra features. If you pay for it, you get some extra perks. But like I said before, I don't think you need to use more than the free version. I haven't ever had an issue with it, so I definitely recommend that you just explore the free version initially, and if you would do feel you need anything extra will then just go and pay for one of the paid options. But like I said before, I don't think you'll need it on. If you go to the product, you can also see a lot of more of the features like that page working in the home page. That little table that we just saw a moment ago had a beautiful summer, I guess. But if you go here, you'll find a lot more. I guess information about each of those features some examples. But you know, when they're talking about planning, what they mean and you can see here, this is a really good example of a camp on board right here. You know, you can create your user stories, etcetera, very five package. And these some of these features. Like I said, our for developers. So don't worry about them. If you're not a developer gay, just don't use them. That's it on. If you're a developer where you're definitely wanna know what going out, want to explore a lot of those other options on those features, you know, that have been designed specifically for developers. And getting up is awesome for developers, developers love. It s So we go back to the home page, and now I'm just gonna take you through a real world example of how we're using any one of our scrum projects. One of the rise of projects. I'm just going to click here on sign in. So right here under signing, we're gonna enter our details and then just sign in. This is what it looked like. And you have, you know, your top. Many here on the left. There are some other things you can configure here on. There are some things here on the left hand side as well. That is your menu. So I'm just gonna go here and show you how we use this is our camera on board. So we created, of course, a project which is this RDM project. And then within that project, we created our user stories with which engaged love they call them issues issues. Just think of them as your user stories. And then milestones are pretty much her sprints. You know what? We would consider our sprints and then, you know, you can have your ward and look at your Cambon board. Or you can go within each milestone here, which is spring. Get loving, get love terms. Or we can use this to, I guess, adjusted to scram in agile. So there's no we've done it. And I'm just going to show you here that we created all of our screens between now and the end of the year, right? So they were doing Weekly Springs on this project. We're doing daily stand ups. I guess I want before I show you the camera on board we're using on this kid Lepic Real world example of how we're using it in one of our projects. Let me just walk you through a little bit. It's on the things we're doing in our scrum rituals and what we're doing with this product , right? Like I said before did, Lab is a little bit more robust, more complex and trail. Oh, so if you're feeling that it's confusing that you don't want to go through the learned how to use give love, that's okay. Go back to trailer. Trailer is really good. I love it. I use it on a lot of my projects. But today, on this example, I wanted to show you that there are other tools out there that are a bit more complex. More Rob Austin Trail Oh, which you can also use to manage your scrum on your agile projects. Now, this particular project that I'm gonna be talking about I'm walking you through today is a research project in which we're helping researchers develop research that of management plans on this project, we're doing weekly sprints, which is why you see here the date. So we did. You know, we've added a date on when our spring finishes on. Here's when it starts and went finishes. All right, So instead of calling or sprains, you know, spring the wine spring to a spring sear three forints, etcetera. Which you can't. Of course you can do that. I'm not saying you don't. You can't do it. In our case, we decided to name the Springs with the date that they were finishing. That's what you have here is potash, you know, stash spring 2019 June 17. So this is year, month, day. Andi Stashes just the name of the product that we're developing on. And here you can see that we set up our weekly sprints between now and the end of the year . So if you scroll down, we have up until December. Alvar Springs have already been set up on by set up. I don't mean that we defined what? We're gonna be doing an interest sprint. I'm just talking about the set up here in the system of us having to spring ready so we can start adding or user stories. And we do have a backlog as well here. So you can set up your backlog, start doubting your use your stories. But just to show you an example on here closed, you know, our previous springs with which we already finished. This is the one we're currently working on. And these are the upcoming sprints, the one we're currently working on. We've completed 16% of that sprint. So if I click here, it's gonna take us to our camp on board. So we have here are basically are to dio are doing and are done. And like I said before, don't worry too much about the word issues. This is just how just how good luck calls it. But we refer to it here as user stories. As you know, in our Skomina agile process, I guess like this name is just because you're originally when they develop kid love. They were thinking about issues when they people tracking their issues are working through issues, and they were just using the system for that. They haven't changed the terminology. I'm not sure they'll change it, or they'll allow you to customize their in the future. But don't worry too much that about that, that's just semantics. That main thing is that the tool is there and you can use it and that you know that you know, when we're talking about issues are basically in the context of Goodlatte referring to our user stories. So here you can see their user stories, they're numbered, which is, I think it's pretty cool because he's hashtag 9 49 is something you can use to reference you know, one user story with another one, or link them if you wanted to link them here. Some labels and these labels that we've added our basic basically relate to different streams of work or different type of things that we're doing with those user stories So, for example, these relates to user story that is for the project board and it relates to the project management stream. And as you can see, here is my name Mauricio. So I'm the one working on this one and there's other people working on other ones that you can see. Moyes is working on this one and there are other people working on the different user story . So we help a bunch of other stories in the sprint. Here are the ones that we've already completed. So we have to in our to dio 19 that are in progress we're doing and then for that have been completed or done right and this shows you the overall percentage of completion. Now if we went back and I just showed you here what we've closed So these air previews springs that we've already finished. That's what you see here 100% complete and you can see here a little bit about the number of users stories that we complete in each of those prints which in a way, could be seen us our velocity. Although velocity is not the number off user stories, but more the number of story points by because in this case, we're actually in this In this context of this particular project, we're not assigning story points of the user stories. We could use the number off user stories. That's a bit of our measure of our velocity in terms of how many of them we are completing through each sprint on does just like I said before, helps us a beating are planning or right guys. Like I said before, I just wanted to show you, and I'm going to go back to the current, you know, sprint that we're going through. It was just on. The purpose of these was for me, just to show you how we can add on how we can use get lab justice. Another example is another tool that you can use to manage your you know, your projects, your scrum project on your agile projects on. If I click here on this, you know one of these, for example, I'm just gonna go into them to this one that say, the's user story here. It'll show you more details on it and you can add questions around this eso It allows you to comment It allows you to add, you know, attach things if you wanted to attach a file. So it's pretty cool because it allows to have a kind of like an ongoing conversation about the different user stories that you're working on. And it will keep track of what people are doing so you can see a little more information about different user stories if you just click on them and you can add more details to it. You know, people can have conversations, ask you questions like etcetera up and you can attach files. And here on the right hand side, you can edit who is working on it, which spring it's part off, you know, labels. If you wanted to have a label and so forth. All right, guys, see you in the next one. Cheers, bite. 38. A Kanban Board Example in Microsoft Planner: Hey, guys, in this part of the course, we're going to see a real world example often agile. Cambon board for one of my agile projects, using Microsoft Planner and Microsoft planner is a really good tool to use for your actual camp on board, because it pretty much allows you to do everything you were doing. Another to elect Trillo. But right there directly in the office 365 suite of Microsoft, which us you already know, integrates seamlessly with all of the Microsoft brought such as Word, Excel, PowerPoint, one drive, etcetera. So it's a really good tool if you're working in a corporate environment or in a company who used his office. 365 If you're in a company who's using office 365 Probably the best tool you can use for agile Cambon board this Microsoft planner. So Microsoft Planet, of course, has its own terminology that Microsoft uses such as, for example, buckets for the columns that you see here. But don't pay too much attention to that because mainly, basically, what you can do in Microsoft planner is personalize it to whatever you like, and in this case, what I have done is I've personalized each of the buckets or what Microsoft in Microsoft Planet calls buckets or for US columns. Here, I personalize it to the columns we would normally have in a natural Cambon board. So I have here that to do, doing Q A or quality assurance done and then parking lot off or ideas, which is basically everything that is out of scope from the project. All right, now, generally, when we're having our adult can one board we want to adhere our user stories right? And if you remember, the user stories are basically product features that are coming from their projects, requirements around things that need to be done right. That's generally when you're thinking about the theory off, agile right. But in practice, we know that this generally tends to be created as tasks. So what people are working on in the project, which we commonly refer to US product tasks or tasks, end up being pretty much your user stories. And that's where you're seeing here on screen. Now I know that in theory, that is not exactly, ah, 100% accurate in the sense that tasks are not necessarily user stories because a new user story ultimately needs to be driving, generating and creating value for the end user. So you might have a task that you might need to do its part of the project. That doesn't necessarily provide any value to the end customer, but you still need to do it right. So the best way and the way I recommend to all people working on agile and these from years of practice and years off knowledge on agile is that you manager product task in your agile Cambon board as you would your user stories. So basically what I'm trying to say here is your user stories are pretty much equivalent to your project tasks, right? Or your project tasks are pretty much equivalent to your user stories in agile All right, So I've talked about before, and you might have heard me in other parts of the course took about user stories that they have a certain way of being written right? So they have ah, format, right Normally that format, or the way in which you write user stories goes something like this, as uh and then the role I need to and then the what So that, and then the Why the valley? The reason you're doing that right? So, for example, as a developer, I need to create a Facebook logging so that it's easier for users to log into the site. Now that's a mouthful, right? That's a mouthful. It's a really long format, and that's what agile in theory requests and asked that you do on. I think it's OK if you want to do that when you're starting or when you're initially getting family are with agile or if you wanna, you know, follow the rules by the book. But in practice, what happens is it becomes a bit repetitive when you see as I I need to solve that block right as I need to so that blood it becomes a bit repetitive and redundant. And then it just is something extra that you have to write because we know human nature is about abbreviation keeping it simple, which in a way is what agile also is all about. That's why you see here that in our user stories for these project, we haven't used a four month off as I need to solve that block. What I recommend people that are working with me on Nigel projects is that they start the user story with a verb, right with verb because of birth implies action. It's something that you need to do. And that is basically what a user story, in essence, is something that you need to do that delivers value for the end user or the project right ? Something that needs to get done in essence, what we would normally call in projects a project task. Right. So this is a magical fragile in an agile Cambon ward. You can manage your user stories and you can manage your springs, and you can see where the project and the people are part of the product are in terms of their performance in terms of their execution, right, because you can easily see, as you can see here at a glance like you can see in Planner, Microsoft Planner allows you to assign the role that the user story to someone that is to a specific person or to more than one person, that there are two people working on that user story, right? And that's why you see, for example, here in this part below, this is me and Maurizio and this is Suzanne was someone that's working with me on this project. These user stories being assigned to Mirage is working on this other one. Here's Kevin working on another one hears me again as well, right? So basically, in this project, what we're doing is working through weekly sprints. So we have a weekly spring cycle. We do our spring planning session. Well, Thursday's and then every Thursday, we assess how we went on the previous sprint. We're doing also our daily stand ups that normally when we're doing our daily stand ups, it's a little bit more informal. So we don't have these. You could, but we don't in our daily standards. In this particular case, we don't actually have these digital board with us. When we're talking about our stand ups a little bit more informal. It's a very short meaning, but we're doing our weekly spring planning. We actually through go in detail through the actual Cambon board, and as we're going through the agile Campbell on board, it's a bit like a roundtable on. We can feel ter the user stories by the person whose executing them so here as you can see at the top, and I'm gonna talk a little bit about Planner. So, for example, here in the top, many of planner you have you have members or people that are part of this project. You have filters and have group by bucket, which is basically another field to the way you see the information. So right now I'm filtering by Bucket, but I could also do assign to it would basically show me all the user stories assigned to a particular person. I could see my progress by Judeh by labels my priority so I can filter the information by different things. And in this Sunday's gonna quickly show you that I can feel trade by assigned to. So it's basically showing all the user stories. Who's assigned. Ho has each users to reassign. So, for example, like you can see here that I'm working on to at the moment and they've been completed 29. And if I scroll to the right, I'm going to see that for the rest off the project team. You know what? I can see what they're working on each individually with their user stories on how much they've actually completed so for example, here for Kevin because he's working on three of them and that it's already finished two or right up to use their stories. And like I said before, we're doing these by spring. Now, this is why me using the filter assigned to I'm just gonna go back to buckets and we keep agile. Come on, board configuration that I manually set up for these can been bore here in Planner. And as you can see, I have a to do doing Q A, which is crawling quality assurance or done now, as you're moving user stories between the different columns, it doesn't necessarily mean that, for example, the this isn't necessarily mean that all use your stories have to go through Q. A. Right que. A quality assurance is basically when you want someone to real someone else to review something that you've done to perform quality assurance on what you did So some things. For example, I might be working someone Developer might be working on user story, and you might want a tester to look at it or him. Or he might want me as a project manager to review what he did on just to check it so we would put that user story here in Cuba. Honest and I we would actually re assign it to someone else. And then after we reassign it. So, for example, here, let's say it's my job to review this. I would change this from here. I would remove Suzanne because she's not working on these anymore. And I would assigned myself here. If I click on a sign I search for my name. Mauricio, This is me and I signed that to myself. And that basically means on I'm gonna have here. This is ah, medium complexity task, which has three story points you can see here, all right. And I'm basically now that's saying this example that I'm giving you right now live I'm basically reassigned these user story to myself so that I would actually Qiwei it. I actually review what Suzanne was doing before because she finished the user story and then she wanted me to check and see that I am happy. Once I'm happy with that. I would just move it to the done column in the actual camp on board, and then it will automatically be marked complete. My planner or alternatively, I can just take here, and it will mark the test complete. All right, but because we're still working on this one, I'm gonna put it back here, and I'm gonna reassign it to Suzanne, who is a person actually working on this. So I'm gonna sign this to Suzanne, and I'm gonna reboot myself from it because I'm actually another working on this ist. It's test. It's a user story that she's working on, and that's why I left it here to just to show you quickly. All right, So Microsoft Planner, you have here basically are kind of like cards similar to what you would see in trail. Oh, and you can move them across the different columns in your agile Cameron board, which basically allows you to see what is the status off the task or the user story in this project in this sprint, Right? Like I said before, we're doing weekly sprints on this project. And one thing that is important, which you might be wondering, is, how do I reflect on how do I put the story points for each user story in these agile can been bored. So the best thing I'd recommend for you is that you use labels. So if you go here, I'm gonna click on this. Particular creates like that for fear. Pilot results these user story and you see here than Microsoft Planner has labels by default. These appear empty and you can actually type text into them. All right, so we basically in the project team, we assign this three colors a green one, the orange Juan and the red one. Low complexity meat complex and high complexity. Local black city tasks have one story point, as you can see here when I'm holding over this one story point, Orange has three story points, and you said, You see there that it says for this task Nice Microsoft's planner terminology because that is common terminology used in any project. Like people talk about tasks. That's how traditionally people have managed projects and that's hope. People understand projects, But like I said, in agile, we generally don't talk about task. But instead off we were talking about task We talk about user stories. Doesn't matter. Like I said before, this is just for, you know, Microsoft Planner uses the terminology task, but you can refer to it in your team and in your agile projects. Ask user stories. Like I said before we go to the theory of valuable user stories are not necessarily is exactly equivalent to tasks buying practice. When you're implementing and working through your agile products, you will see that pretty much tasks become user stories. And that's why I say to you, Don't worry too much about it and just think of your user stories as basically tasks within your agile projects. All right. And then you see here that I have a medium complexity task. We chest three story points and then a red one, which is high complexity Stass core user story, which has five story points. So basically 13 and five right, and that is the story point scale we're using in this particular project. In this particular example, that doesn't mean that that's the exact, you know scale that you have to use in your agile projects. Just that's just what we use in this one. And that's basically what I would recommend. As you know, you can use custom made scale. You can create your own scale. You can use Fibonacci sequins as your scale you can use. You know what pretty much whatever type of scale you want to use. But because agile is also about seem place city flexibility and agility itself and doing things faster and keeping it simple. What I normally recommend my students is that they use ah, very simple scale. A scale of 1351 local black city three medium complexity five high complexity user stories and then same in terms of the numbers. One story point for local plexi. Three for medium complexity on five for high complexity. And that's exactly what you're seeing here in these example of financial Cambon board in Microsoft Planner, Do you see here the colors low wants to re point the green one. The orange one. Mid complexity. Three story points on the high complexity one five story points, which is the red. All right Now, I could use that also in the filters hearing Microsoft Planner I can say here feel ter by and I could go here, and instead of filtering by people, I could actually feel to buy label right so I could actually feel to hear and say Show me all the one story points user stories. If I click here, you see that nine seeing on Lee the ones with the green label which, like I said before, are the low complexity story user stories which have one story point. So basically, if I was looking at this print, for example, I would add up. The story points from all of these user stories to get how many total story points we having that sprint, right? That's basically how you do it. But you wouldn't do it, of course, just with their low complexity story point. But all the story points that are part of that sprint. But like I said before, don't worry too much about that right now. I just wanted to show you real quickly an example of financial Cambon board like a real one in practice and how we use it. All right, so we can also feel turn like we did before. I'm gonna just scroll on the top by the labels and again labels. He's a terminology from Microsoft Planner. We've used it here to convey and showcase the number of story points. It doesn't mean you have to necessarily use it this way is just an example on how I would recommend that you use it in your agile projects. Eve, you're creating an adult Cambon board in Microsoft Planner. All right, so we could also feel to buy that mission. See, also that made complexity use their stories. So and I'm seeing the mid complexity and the low complexity. But I could remove the local black city right, which is the green one. Let's remove their green ones from here. So if I click on this again now it's showing me on Lee the medium complexity user stories on. Then I could do the same for the high complexity here on just like the red on de Select their Orange. And then I would only would see that I don't have a lot off five story points user stories in this particular sprint basically one in progress and what one that's been completed, All right, so I'm gonna clear this a week. See again the whole Kammen board, right? But this is basically how you can use Microsoft Planner to create an actual camp on board. You can rename what Microsoft Planet calls the buckets or the columns to to do doing Q A done on parking lot ideas. And then as you're creating your user stories, and if you're wondering how you do it is very simply, Microsoft Planner. You just click here on the plus button on that's how you and your easier stories. So, for example, if I click here and I do example, use her story All right, this is just an example, and I'm gonna click enter, and then I'm just double clicking on this so I can expand If I double click or I just click on it and I can expand these your story. I'm gonna say this has five story points. So it's a high complexity user story, and I'm going to say, Let's assign it to Mauricio, All right? And this is just planner functionality, so I could give it a priority if I wanted to. I could write a description. I could create a checklist. I could add an attachment. I could add comments. So this is one of the really cool things from Microsoft Planner. It has a lot of really reach super easy to use super simple functionality. Now, if I wanted to add a due date as well, I could, and then it would just, for example, let me just go back to the U cities, This calendar here and that it's in red. It basically means this isn't over to you Use your story Something that should have been finished already and hasn't been finished. Right? So that is one of the beauties off Microsoft Planner. You know, you can use all of these and you can see here this little icon number one. It means thes user story has one attachment. And if you're wondering, why would someone want to ask trying and you date or an attachment to a user story? Well, because it used her story could have a particular day willingness to be finished, and it could. And the attachment could just be supporting material or supporting documentation. All right, so I'm gonna delete these example. Use their story that I just created for you right now, But like I said, here, you can assign it to someone else. You can copy it, or you can delete it. I'm gonna delete it because this was just a quick example just to show you how how to create a user story here in Microsoft Planner. And if you're feeling that I'm going too fast over it. Don't worry. You can rewind. Of course, because this is a video. You can pause it. You can replay the video. I like you. So before, I'm just going to let this one just delete it. But like you, So before you just click here on the plus button and then you create your user story on Like I said before, I recommend that you start with a verb, right? So, for example, create Beeld. Develop right. The sign. Right? Check. Basically a verb, right. Something that implies action. That's something that I recommend to people when they're riding the reser stories. Now, because we're not following that foreman also, as I need to So that block, which is a very long four months for writing and user story What I also recommend to people when they're writing the reserve stories in practice, in real life, like you're seeing here, is a Like I said before, don't use the official traditional agile template because he used as I need to solve that block, it becomes quite long and it also becomes repetitive and redundant. So start with a verb on the other thing. I always say to people is right your user stories in a short, concise, relevant Wait, you know, don't right them. Don't tell a novel in the user story. Just keep it to a one liner that anybody that recent use their story can understand what he's about. Like update Exceptional Forum Update. These and I like this unless this percent this enabled enabled these analysis. So anyone that rich this at last can quickly tell what it's about Now, if you wanted to have more information on that, you can. You can just click here and you can add a description. Here are very long text if you wanted to, or a long text here in the comment comments section. But, like I said before to keep your adult Kevin Ward beautiful, like you're seeing these on screen, which is super, you know, it just looks really good. It's easy to understand. It is easy to work with. It works at a glance. That's the whole purpose of an agile Cambon board. That's how it's meant to be. It should be short. It should be relevant. It should become size. It should be easy to understand, right, because basically what an actual camp in board allows us to do is to check what is the status of the project at any point in time during any particular spring, Right on bases, how we're managing in our case on these examples, as you're that you're seeing here right now. Now there's something I really like. Also about Microsoft plan is that you can see here that is showing that we've completed 100 23 use or stories, right, and you can scroll and you can see all of them that have been completed. And it just keeps all the traceability off everything that you've done right. Microsoft Microsoft Planner also has other functionality such as charts. If I go here to charts, he's gonna show me what's not started. What in progress would slate what's completed? And I can see here some graphs as well, and I can see here the number off this is showing me basically that I have two tests that I haven't started to use her stories and it shows that by, um, team member, right, So you can see here different colors in progress late. So I thes guy has won one task over Do you use your story over due to two in progress and so forth. These are just some of those graphs that automatically come from Microsoft Planner, and it has a lot of other options here that you can see. And I'm not gonna go into them in detail because this was basically Maura about the agile can been bored. Now the charts here, as you saw before these are like Michael's of planner standard charts. So they're not a burned down chart or a velocity chart or any other type of chart he could use in agile, such as a burn up chart as well. But I have included some of those templates for you in the course, which you can easily download, And they're just excel, you know, templates that you type in, and they automatically calculate, or, if you want it to have, like an automatic diagram, you know, now automatic burned down charge, velocity, etcetera. Probably the most robust tool for that will be jezeera from inflation. That's probably the one that has all of those graphs automatically incorporated into them. For things like planner or travel, you kind of have to manually do them or you you have to have Adam's or pay extra functionality to get that added onto them. So it doesn't come by that by the fault, like it does injera. So that's an advantage of Ghira. But gee, Rolls was a tool is a little bit more complex to manage is a little bit more complicated and more complex to understand as well. So if you want to go really simple, really minimalistic, I definitely recommend that you used either trail Oh, or Microsoft planner, if you're use it. If you're working at a company that has access to office 365 right on Microsoft Planner is one of those APS that it's part of office 365 So, alright, guys, as you can see here, this is a really simple example. Off an agile can been bored here in Microsoft Planner on. We talked about user stories, story points that columns that are part of the campaign board, how you contract completion, how you can create a new user Stories here and Microsoft planner. How can you assign or reassigned? Use their stories if you need to how you can move them across as you're more as there. You're making progress, the different faces of the project, and that's basically eat right. And as you already know, they don't have to be for everyone exactly what I'm showing here, in the sense that you don't all have to be using wiki sprints like I've worked in parts where we have fortnightly springs. I have worked in other places where we had springs the last three weeks, and I worked in practical that last up to four weeks, which is probably the longest you wanna have in terms of your sprint duration. In this case, we're doing weekly sprints, which is not something you can perceived here so much in the camp on board, but doesn't really matter because the people working on the product team we know which are the user stories we're working on each week because that's what's reflected here in the agile Cambon board. What you see here is what we're planning or with planned for a particular spring. After we complete everything, we move them to the done, and if we haven't completed everything, then it moves across the following sprint, which is something that I get asked about all the time. Do we move user stories across to the next print. Four. Do we put them back in the product backlog, or what do we do with them? And we didn't complete them. So basically, yeah, you could put here another column. We don't have it here on these this camera board example that I have your seen on screen, but you could put another column for your product back Look, And then if you didn't complete something, you could move it back to the product backlog, and then you can reassign it for the next print. Or you can think and just simply move everything across. It's really up to each agile team, and each agile team is different, and the context off each agile team is a bit different as well. So some teams just move everything across ours, reassess If you ask me what you should do. I basically think you should look at it on a case by case basis. So after you finish each sprint as you're doing your spring planning for the next spring, you want to look at what story user sores you didn't complete in your previous sprint on if they're still relevant, and if you're stealing to complete them in the short term will move into the next spring. If you don't if they're no longer rebel relevantly, something's changed. Put him in the product back. Look, As you already know, agile is not rigidities flexible on. We're open to change all the time and things change rapidly. An agile. Which is why following our Rachel, such as the daily stand ups and retrospectives, the you know, spring planning sessions, the demo sessions and so forth is so important because a bit like culture. Alright, guys. So anyway, I just wanted to show you this example off our agile Cambon board here in Microsoft Planner because it's something that I know people are really interested in seeing all the time you know, real world examples and how using a wish tools I'm using. And as you've heard me talk about before, I'm not particularly married to any one single tool. I'm constantly playing around with different tools, and I think that beyond which tool you use, it's more around the process, that culture that everyone feels comfortable with what they're using in our case in this particular business and in this particular project, everyone on the product team has access to Microsoft Planner. They all know how it works is super easy to use, so we all use it in this area. So what we have, And like I said before hearing the done, you can hide it if you want to hide it or you can expand it. Microsoft Planner is pretty intuitive. You'll get the hang of it really quickly and really easily on, Um, anyway, I hope you found these part of the course and this lecture on a riel world example of idle Cambon board using Microsoft Planner really valuable and really helpful. And I know there's something that people want me to do all the time. They want me to walk them through reward world examples using a particular tool and how I use it, and I'm sure you'll get a lower value from it. And if you have any questions, we'll reach out. No worries. Happy to answer and happy to help where I can write guys. Cheers. See in the next one might 39. Why Companies Love Scrum & Job Opportunities: you've already heard me talk about why companies love scrum so much, but I wanted to summarize it in a couple of bullet points for you, and it's pretty much what you're seeing on screen. You know, people love Scrum because he provides tangible benefits really quickly. Often eternity, Vly, because it creates a mindset and a culture off result orientation on, you know, the lettering often delivering quickly and also because people are growing and continuously improving and people can see that. And I think one of the biggest things also why people become so, you know, attached to scram. If there they start using it is because they see the difference on how it helps their business and how it helps their project versus whatever they were doing before, which, of course, was always or generally taking. I love longer and a lot of time is not enabling them to meet and reach their goals. Real life example Here A few years ago, I worked on this project and he had gone through five different product managers. He had taken three years, and the team had Lille, the team that I was working on, that project in particular had little to show for themselves. They were trying to actually deploy these new technology to about 20,000 users on. They had only reached about 500 of those. Imagine sounds crazy, right? But this is difficult and this happens in many businesses in the world where they're spending millions of dollars in the hundreds of millions of projects. And a lot of times the results are not what they're expecting. So when they call being to work with this project team, one of the first thing I said to them is I wanted to completely change the strategy and the methodology and everything that they were doing and shift the scrum on. I coached them and explain to them what scrum Waas and I kind of took on the role of scrum master in this project. We worked really hard and you're not going to believe me. But it's really I'm talking about a real life example. In less than three months, we delivered these to these 20,000 users. This new technology. He was a super highly successful project. People love the project. They were able to start using the new technology. He just enabled them to work more collaboratively, more productively. And we did this seriously what they had haven't done in, like, three years with the busy in three months. And I know it sounds crazy. I know it sounds, you know, a bit fantastic, and I get out of out of this world. But it's it's really I'm talking about a real life example off a product that work on a few years ago, and he was amazing. You know, we received a lot of recognition for that. You know, people were receiving awards that were receiving bonuses, financial incentives because of the results of were accomplished. And it's really exciting to say that. And I'm not saying you should be doing that or you should be working its crime because of the reward so you can get What I'm saying is it can be very rewarding, even if you don't get you know these huge rewards or bonuses or whatever just the processes you have, you been able to reach your goals on time on budget a lot of times ahead of time, ahead of schedule, then it is just super rewarding, and people feel very excited of working on on scrum projects together on projects using scrum because they can see the value of it. That's why that's why going back to the to the initial part of this lecture, people love, scram. And that's what companies love scrum. And that's why there's such a high demand for scrum masters and people with scrum and agile knowledge, because this is just becoming a bit of a trend in the world in which companies want to shift more on war to scrum or one a shift more more to agile methodologies. So I'm pleased to report that there's a ton of job opportunities out there for people with scram knowledge or it's crime certifications. So I'm really glad for you because you're going through this course. You acquired a really important skill set and a really important amount of knowledge about scrum that will allow you to either war come scrum projects share knowledge with people at the office, apply for scrum master rolls or scrum roles. And like I said before, it's just a very big market worldwide with an appetite and demand for people with scram skills and scram knowledge across different industries, different types of projects and all over the world. So I see people applying and moving into scrambles all the time. And, you know, it's a really fulfilling career. It's a very exciting career. It doesn't matter if you're a B, a r P m or even someone that hasn't had this type of exposure before. This allows you now to apply for a type of career and a type of career move that you might have had the opportunity to apply for before so again, really excited for you guys. What you do with the information and certification that you're getting from this court is up to you. No pressure. Of course, if you didn't want to do anything in particular, but just more, this was more a learning experience for for you. I'm God that he gave yourself the opportunity anyway because like I said, there's a lot of advantages and a little things you can take from the scores and apply in your real life projects. And even if you didn't apply everything but to some of the key concept of some of the things that you learned in the scores, you're gonna start seeing that off, you know, value and a lot of differences in the way you are working on on your product and in the delivery on the outcomes of those projects. So I'm sure you're going to grate on, you know, if anything comes up and if you have any questions or anything, don't hesitate to contact me or which out. Alright, guys, see on the next one by. 40. The Scrum Process and Scrum Recap: So in this stage of the course, we've already covered all of the different concepts that are part of scrum. The different artifacts, rituals, tools, principles, pillars, values pretty much everything that is part of screaming, including the roles that are at the essence and at the heart off scrum. And now I just want to just put that all together into a single diagram in a simple illustration for you to understand the whole process and to end. And that's it. This is it. What you're seeing on screen, as you can see, is very, very simple because that's how scrum is. It's a very simple framework in a very simple methodology for you to deliver projects and let's go back from left to right. We have the product backlog and then from that product backlog, which is everything that we need to deliver in the project. Before we started sprint, we create our sprint back look, which are the user stories, and we're gonna be living that particular sprint. Then we go through that sprint that is generally two weeks and as we're progressing and either terribly working through our sprints were also doing our daily scrum on our daily scrum is a 15 minute meaning in which every day we made together with the team we go on what was work today before what we're currently working on. And if there's any issues or impediments for us to meet the sprint objectives and once we finish the sprint we deliver on increment or a deliverable on, then we repeat the whole process all over again. So that's why you have those serials in Sprint and daily scram because that's a bit off cyclical process and it's a continuous process and that's where we call it interrogative development because it's continues and it builds on top of what was done before, as you can see on from the graph that you're seeing on screen. So that's pretty much it guys. And I know when you started the course and you had no idea what Scrum was about, you were kind of thinking on what and how complex he would be and you kept hearing about user stories, sprained sprint back, look from the back plug, daily scrum, scrum, master product owner and all of these terms seemed a little beat. Bizarre, right, But now that you've gone through these cores. All of these is, you know, put together in this very simple diagram that anyone can understand on. You can appreciate in here the beauty and the simplicity of scrum and why it's so powerful . Like we said before the key thing and the reason why it's such a powerful methodologies because it allows you to deliver quickly often and to meet those business objectives a lot faster than you would if you were just following a sequential traditional project management approach, which is known as a waterfall methodology. A waterfall approach on to complement what we saw before in the scrum recap we're gonna cover again the different roles that are part off Scrum, which are the breath owner, the development team on the scrum Master. Those three rolls added together, are what we can see there, describe team and just remember that the product owner is someone that he's representing the customer on the needs and priorities of that and customer. The development teams are the people that are actually doing the work on the scrum. Master is a facilitator and a champion of screaming the whole process that ensured that the team delivers on time on track on on budget, right and as we saw before in scrum with deliver v Esperance that generally and typically last two weeks on the spot us that execute for that execution process, we have what we call a day's Crump, which is a 15 minute daily meeting in which the team gets together and talks about what each person in the team did the day before, what they're doing that on that particular day on, if they have any roadblocks or any issues or any impediments that are not allowing them to meet their sprint goal, that's it. Is that simple as that and a seem? Plus, it s you're seen on screen and the beauty off all of these, like we talked before, is that it allows us to deliver quickly often and to meet those business objectives and those business requirements