Scrum: Agile project management and requirements gathering

1. Welcome: Welcome to this course on Scrum. Whether you're a ScrumMaster, a project manager, a developer and engineer, a test it with just looking at Agile, I'll then this is the course for you. Scrum is project management framework. It was originally developed for software development, but it can actually be used for anything. So the skills I will teach on this course as much as possible. I'll try to apply to all environments. But we are going to go through with a real case study. So we're going to look at building an e-commerce platform is a software application. And we're gonna see how squirm applies to that. So you learn the theory, the practical, and we'll apply it to this situation as well. So if all that sounds good, then let's get started. 2. Scrum basics: Let's start with the basics. So what is grown? Well, it's project management framework. It helps you deliver projects, structure them in a way that they work. So it was originally developed for developing software, for developing technical projects, but has since been applied to a whole range of topics. So kind of software development is its home. But actually you can apply squirm to anything and it works really well. I've used in my personal life, I've used it non type projects. And those valving really good. Scrum is part of the Agile family. So agile is a movement. It's not one thing. Agile is, is a way of being and working. And you've got the kind of cool philosophy of Agile. But then you've got specific implementations, things like Scrum, things like Kanban, that kind of a manual of okay, well here's how you put those Agile principles into effect. So squamous part of the overall Agile movement, and it's one specific implementation of that. Scrum. And Agile in general is really designed to reduce project failure, make projects more reliable. So in the old way, projects tended to fail a lot. And so after all came along and said, How can we do this better? How can we reduce that? And we'll get into more about how it does that as we go on. So, how does Scrum work? How does it achieve all these things? Let's explore that in the next couple of lessons. 3. Agile vs waterfall: Let's compare an old-style waterfall methodology with a more agile scrum based methodology. The old system, we'd have everything in big steps. It'd be a big specification phase. Then all the development work could be done, followed by the testing and the user acceptance. Now here's where that goes wrong. We might, it might take us way longer than expected and we run out of money at some point, we get to the testing stage and we realized that we need the requirements to change, but we've already done all of the development work. Or we get to the User Acceptance Stage and we put it in front of the client or the customer and they don't like it and they need a want changes. And then what are we supposed to do that because we're already in the User Acceptance phage. So instead of this, Agile proposes that we use an iterative process in which we do lots of little steps. So we do a small speck, small build, small tasks, small user acceptance, and then we start the cycle over again. So rather than having these four big blocks where everything is done at once, we have these little quick cycles. And the advantages of doing this are things like, well, we can make a release after the first cycle. When they're old waterfall methodology, you'd only get to release at the end. But here we build something very basic and we can release it after the first cycle. We can also put it in front of the customer so they can see it. And they can make changes if they need to, if it's not matching up with what they want. And these changes are fine because after we've done the user acceptance was the first round. We go back into the specification phase workout. What the next thing is we need to build and then we build it and test it and give it back to the customer. And we keep going around in these quick cycles where we gather loads of feedback and we get things out early, which reduces the chance of failure and means it's going to match up with what the customer needs. 4. Strengths and limitations: Let's consider some of the strengths and limitations of scroll. One of the big advantages is voids project failure. So we talked about this idea of waterfall projects taken ages, getting to the end. And maybe they don't get into the end because the cost overrun or they do and the user doesn't like it. And the whole thing is a failure will Scrum and Agile in general really avoid that? Customers can see it earlier so they're happier because they can see the progress and they can see that it's matching up to what they want rather than getting something at the end that may or may not be what they want. It's very good reporting, changing user requirements. So if the client gets it and they say, Oh, I need to change this or this isn't quite working. It's much easier to change if you haven't built everything. And if you're working in a methodology that says changes, a fine change is a part of the process which they are, which is the problem with waterfall is that the client is going to make changes as you go through the project. And you need a way to handle that. And it's iterative methodology really helps with that. It means you can get the first version out earlier because you don't need to finish the whole thing to be able to ship it. You can build the essential functionality, ship it, and then keep building at after you've already released the projects. Now that all limitations to Scrum and Agile. So one of the big ones is that it takes a bit longer. Sometimes people think Agile sounds a bit faster, but it's not. It's designed to reduce the failure rates. So Waterfall, Waterfall is quite efficient if you get everything 100% correct. So if you have 100% planned and built and then test it and then delivered, and everything works perfectly. And there are no changing user requirements that would be faster than this iterative cycle where you build a bit, you review it, you build a bit, you review it, it would be faster. Now, I've never seen a project where it has been planned to 100% and then we know changing user requirements. So I think agile works out much better. But hypothetically, if you could get all of that lined up, then waterfall would be faster because Scrum works in this iterative cycle, it does take a bit longer. Stakeholders don't always like it. So if they're from the old school waterfall style that probably a bit nervous about adopting this new agile methodology. And sometimes they're worried that if we're developing this iterative cycle where we're showing the client a half built piece of software that tends to panic them. My experience, clients love it. They really engaged. They want to see progress and they understand that they're not looking at the finished project. But a lot of old school managers really worry that we show, show them a button that's not completely finished and the client will assume it's finished and expect it tomorrow. And it can sometimes be difficult to manage those expectations. Scrum has a lot of flexibility, but in some way squamous, inflexible. So it works in these sprints of typically two weeks where you say what you're gonna do at the start of the two weeks, then you do it and you don't change that. Now in some ways that's good because if you allow changes within the sprint, then you often get managers trying to shove more working and distracting the engineers and dragging them off task. And it's not great. But there are some environments where you have urgent things come up in squirm isn't as good at handling that as say something like Kanban, which is another Agile Framework, which is designed as a more kind of once you're alive doing business as usual, pushing up fixes, it's more suitable to that with Scrum is more suitable for if you're building a project for the first time. And, you know, you can say, we've got a two-week block here. This is what we're going to get done and allowing everyone to concentrate on that. 5. The sprint: One of the key concepts in Scrum, which is different to some of the other Agile frameworks is this idea of the sprint. This is a fixed period of time where the team agrees to deliver a specific set of features. So it's often two weeks and we say, okay, in the next two weeks, we're going to build this feature, this feature and this feature. So a sprint, we'll have a goal, e.g. maybe the goal is to deliver the checkout page for our e-commerce platform. And that's composed of several tickets that build each of the functionality required to do that. And then we start a sprint and the whole team works together to deliver this functionality. So delivery, completion of the sprint goal isn't any one person's job. It's the collective responsibility of the whole team. So what that looks like in a process is we start with Sprint Planning. In Sprint Planning, Sprint Goal is agreed and we choose the tasks that are going to be completed. So we select the issues or the tickets that we're going to bring in and they become the sprint backlog, which is essentially the to-do list for this two weeks. We then will then into the sprint itself. So the team works on delivering the agreed features and nothing new is brought into the sprint. So when we do Sprint planning, we start this when and then that locks down that sprint, that period of time to say this is what we're going to do and we're going to work together to do it. At the end of the sprint. We then have the retrospective and review. So the completed work is presented at a review and the team reflects on how it went, which is the retrospective. So the two separate events, and we'll talk more about those in a later lesson. And any issues not completed are carried over to the next sprint or they're returned to the product backlog. 6. Sprint length: The length of a sprint can be anything you like. So typically, sprints are done in two-week periods because that seems to work well for most project, but that's not a rule. Sometimes I've done one-week sprints, sometimes I've done three-week sprint. What you really want to do is work out how long it's gonna take you to deliver a certain features, certain bit in the development process and make that your sprint length. So if you've got a really big and tricky feature to deliver a part of the project to deliver. Then if that's going to take you say, a month to do, then you want to make your sprint a month long if we literally can't be broken down. And that's a good question to ask yourself if you're thinking, okay, I need a near four weeks or six weeks sprint or something. Re-examine whether you can further break that down because you probably can. But if it's literally impossible, it's okay to make your sprint longer because you can adapt the length of the splint to fit our needs. Usually two weeks is a good time period. Everyone can get their heads down. You're not spending too much time going through the sprint cycle and you've got a good period of ten working days to get stuff done, but you can make it shorter or longer to suit your needs. 7. What are artefacts?: Artifacts are pieces of information that a Scrum team uses to help plan and deliver their work. So e.g. a. List of features to build would be an artifact. Now this could be kept on a spreadsheet. It could be kept in a tool such as JIRA, or it could even be kept in our heads. But I wouldn't recommend that because that obviously creates a single point of failure. In this module, we're going to explore the different types of artifacts that it's common for Scrum teams to use. 8. Product backlog: The product is the thing that you're delivering and the product backlog is all the things that need to be done. So all of the tasks involved in the project. Each ticket represents a discrete piece of functionality. So one ticket, one piece of deliverable functionality, e.g. if we take our e-commerce store example, then we probably need a view product page where you can click on the product and see all the details. And that has various components as it's probably like a title and description of product photo and some reviews and technical specifications. Now, each of those things might be it's own ticket sitting in a product backlog. So adding the creating the blank page, adding the title, adding the product image, I didn't specifications adding the reviews. These could all be individual tickets because you could deliver these one at a time. You could deliver a page that only has a product title on. And then you could come back later and add a product photo or some product reviews that discrete pieces of functionality, and therefore they get their own ticket. Now tickets can go into a bigger piece of work. So in this case, we have our product page, or product page will, might be what's called an epic. So this is a collection of tickets that works towards a bigger piece of functionality. So our product page as a whole might be in an epic. And then then we've got individual tickets in there. So we've got our product description, product photo, product review, and all of that is part of the product page epic, which we can then roll out at some point. So the point of the product backlog is to hold all of the tasks that need doing. So they'd hold everything for the product page, everything for the browse page, everything for the checkout page, all broken down into individual tickets and separate it out into these epics. So we know which ticket belongs to, which kind of section. 9. Example product backlog: Here we've got an example product backlog. So this is for our example e-commerce store. And we've got our user stories written here. So the written in the user story format that we'll talk about a bit later. But things like, as a visitor, I won't see the name of the product, the product image. And then as a manager, I want to see a list of orders. And in this column we've grouped it by epoch. So these are all the product page epic, their checkout apically order management epic. And we've put a provisional sprint on these here and the status column to say whether they've done whenever we're doing now, or whether they're ready. And there'll be some that weren't ready because we haven't refined them down here. Now there's loads of great tools you can use to manage your product backlog. But I wanted to show it to you on this spreadsheet because I think it's a great way to learn fundamentals. You can do it on a spreadsheet, you can do on a piece of paper, you can do however you wish. We will dive into the tools because they're really important too. That's probably what you'll be using in a real-world business environment. But this is a good way to consider the fundamentals. 10. Sprint backlog: At the start of each sprint, you select which tickets you're going to do in this sprint. So let's say you're working in a two-week sprint. You go through the product backlog and you say, Okay, a, B, C, D, These are the tickets that we're going to bring in and do in this sprint. So once you start the sprint, these tickets you've selected form what's called your sprint backlog. The product backlog list, everything that you'll have to do for the project, the sprint backlog list of tickets that you're going to do for this specific sprint. So when someone is ready to work on something, they go to the sprint backlog and pick up one of the tickets, any of the tickets you can prioritize. But typically inside a sprint, there isn't really much prioritization unless something's blocking something. But if you have a blocker, it's best to leave that to a separate sprint so the tickets can be picked up in any order. And then they go from the to-do column, which is the sprint backlog across the board as they go through development, implementation, delivery. 11. Example sprint backlog: Here we've got an example, sprint backlog. So we've got our columns here with the to-do list, the backlog here. And then as we do these tickets, so if I say picked this one as a customer, I want to see the product name. I can move that into in-progress, then send it for code review. And just keep moving it through the process. And let's say it gets ready for testing. Tests depicts it up. It doesn't work. They could move it back to In Progress, reassign it to me. And it could go back through that cycle again and then eventually, hopefully ends up in the done column. Now these columns can be as flexible as you want. So we might, instead of in-progress encoder view, maybe we want to split that. Add a new column down here. There we go. I'd call him before we might say ready for code review. And in code review. And then once I've finished writing the code, I could stick it here. And then someone else could pick it up from. When they pick it up. It could go into here, e.g. so these columns, there's no rules, but there's some general principles that you probably want some kind of backlog while he needed backlog, and he didn't need that one. And in progress at some code review and testing. Then ultimately they want to end up in the done column. Now again, loads of great tools for doing this, but it's nice to see it on a very basic level. A lot of people use physical boards with post-its that they would move along. That was very popular when everyone worked in the office last thousands of pandemic and remote teams are far more influential. But you can, if you're doing it in a one-person project, It's still a great way to do it because you've got a really a tactile experience of moving the cards along the board. 12. Definition of done: How do you know when a ticket can be moved into the done column? Will an important document here is the definition of done. This is a document that outlines exactly what is required for a ticket to be considered done. So e.g. if we look at software again, an engineer can build the feature. But that wouldn't meet most definitions of done because it's not it's not gone anywhere, it's not being tested. And so the definition of done will list all the steps e.g. it's been built and tested. It's been deployed. There's enough test coverage on there. There's maybe some monitoring and some logging so you can save that feature goes wrong or breaks later. It's been performance and security tested to make sure it hasn't introduced any holes, things like that. All of the additional steps where you can say this ticket is finished, we don't need to add anything extra. We don't need to go back and look at it. We are happy for it to be out there in the wild. In the next lesson, we'll look at an example Definition of Done so you can see what it looks like in practice. 13. What are ceremonies?: Ceremonies are events that helped with the sprint planning, execution, and delivery. Typically, they involve the members of the scrum team, but in some ceremonies, we may choose to invite external stakeholders as well. In this module, we'll explore each of the key ceremonies in turn. 14. Daily Scrum: The daily scrum is a daily meeting. Usually happens in the morning, but it doesn't have to and it's kind of like a check-in for all of the scrum team members. It's typically done standing, hence, it's usually called stand-ups on the PC. Cross agile term, multiple Agile frameworks will use the term stand-up in Scrum specifically, it's technically called The Daily Scrum, but it's the same thing. And the format is each member says what they did yesterday, what they're working on right now, and any blockers, so there's anything getting in the way of their work, they can raise it. Then. The purpose is to help everyone stay accountable to each other. And it's a good chance for ask for any help that we need as well. It's not designed to be a long meeting. It's normally timebox to a maximum of 15 min and it's done standing. So everyone is encouraged to to keep it short and to the point. So if there's anything that needs further discussion, you had what's called take that offline. So arrange a separate meeting. We can discuss it with the relevant parties because chances are everyone at the Daily Scrum doesn't need to be involved. And so we really keep it to those concise updates. It's useful to have your sprint board open while you do it so people can remember what they're working on and talk through the tickets and show the rest of the team where the tickets are and how they're moving along. 15. Backlog refinement: A backlog refinement meeting prepares tickets to come into the sprint. So when you first create your product backlog, you're probably not going to give that much detail you thinking, okay, product page, product image, product, movies. Keeping it pretty simple in that ticket really isn't ready to go to an engineer to be picked up to be implemented. And that's what backlog refinement helps with. So it can involve the whole Scrum team or it could involve say, the product owner and maybe the lead engineer working together. And the tasks of the backlog refinement R21, break down the ticket into its smallest pieces. So if the ticket is the view product page, that can be further broken down into reviews and product image and the page itself into nice small pieces. Then we're to ensure that the ticket is ready to bring into spent. So here we're talking about elaboration of the tickets. What exactly does the product owner does the business want? Are the specification is really clear. Are there any technical notes or implementations that needs to be added onto the ticket so the engineer understand what needs to be done. Are there any notes there on the tester tests to understand what needs to be done? Is there enough information for this ticket to go into a sprint and pick it up and starting working on it without having to ask additional questions. And then we'll review any blockers. So e.g. if the ticket is add the product reviews to the view product page, that ticket would be blocked by the building of a shell view product page. Because if that view product page doesn't exist, you can't add any reviews to it. And so therefore that would be a blocker and we'd need to factor that in. So for a ticket to pass backlog refinement, it should be ready to bring into a sprint. That means it has no blockers, it's ready to go, and it has a clear definition of what needs to be done. 16. Estimating points: One of the things you need to know before you bring a ticket into a sprint is, well, how long is it going to take? Is this a small ticket and medium ticket? A big ticket. We need some kind of rough idea about how long the ticket is going to take so that we can try and estimate how much work we can get done in the sprint that we're currently trying to plan. Now in scope, instead of using time, we use points. And points are arbitrary, so there isn't necessarily a correlation of zero point takes this much time. What you do is you see, you estimate the points, then you see how many points you can get done in a sprint. And then from then on, you know, okay, well I can do we think we can get through two points as a team. So we need to bring in for two points next time. Now, how does this work? If you already need to have done a couple of sprints and worked out what your point values are. Like. How do you start off with that? Well, there you do need to initially come up with a bit of a link between time and points. So maybe you say, well wouldn't point is one day for one person or half a day for one person. And so if you think of tickets is going to take the engineer two days the test or one day, and another day of someone's time to deploy, then you say, okay, well, it's four days, so we're going to call up four points for now. And in point of all tickets in a similar fashion. And then as you're squinting grows and continues and get food multiple sprints, you start getting an idea of, okay, well, this ticket is roughly this many points. And so it's going to take this long to implement. We know we can get through about 30 point to sprint. So we can bring 30 points of stuff into the spin. Points of tickets. 17. Agile poker: A good way to do points estimation is with Agile poker. With some of these cards, you can get them, get them anywhere. And so each team member would get a set of these cards. And the cards have points values on them following the Fibonacci sequence. So you've got like half 0.123, 581320. These ones go to 25, so they do very little buy cards. You would never have 100 point tickets. You've got infinity unknown. And so the idea is everyone get a set of these. Everyone would hold them like a poker and you'd estimate, so you say, Okay, we're going to estimate this ticket now. And maybe, maybe I pick up this one. Maybe another team member goes and picks up this one. And then once we've all picked, we turn them over. I've gone for free, someone else come for eight. So big difference there, we talk about that difference and then we'd agree a points value, but it allows everyone to give an independent estimation. Then you can work out if everyone's picked three except one person. Probably want to go for the free after a bit of discussion. But it's a good way of getting everyone's independent opinion before you come back together and discuss the issues and try and work out the points value. 18. Velocity: We talked about this idea of the points don't necessarily need to match times. You can point to open complexity. So something really simple might be a one-point. Something really complex might be say, a 13 point. And then after you've done a couple of sprints, you kind of get an idea of how many points you're getting through in a sprint. In fact, we normally measure that. So we see how many points we moved into the dunk column in a particular sprint and that could be anything. So let's say the tin got through 35 or 42 or 47 points, whatever it is. Well, if you have those sprint history, so one sprint, you did 55 when you did 42, when needed for it to seven. Well then you know that on average, you get through about 38 points per sprint. So that average becomes what we call the velocity. That's how fast we're moving and how fast we're moving in this case is typically around 38 points per sprint. So once you've calculated that velocity, then, you know, okay, well next sprint, we can bring in approximately 38 points worth of stuff, because that's how much we typically get done in a sprint. 19. Sprint planning: Sprint planning happens at the start of every sprint. You'll agree a sprint duration, and then you work out how many points you think you can complete in that time. So if you're doing, if you're working in say, two-week sprint and you've got a velocity of 38 points, then you probably bring in 38 points with the tickets. If for some reason shorten it. So maybe doing a one-week Sprint, then maps will tell you that you can probably get through about 19 points in half the time. You work out how many points you've got to play with. And then you bring in an appropriate amount of tickets into fill that points value. So if you've got 38 points to play with, you go to your product backlog and you select 38 points worth of tickets, and those become your sprint backlog. So those are the to-do list for the sprint that you're currently working at. This point, estimation can happen in refinement or it can happen in sprint planning if it hasn't happened in refinement, refinements, a good idea. If they've already been done and you run sprint planning, then maybe if on a couple of people involved in refinement and sprint planning is a good time to double-check that everyone agrees with the points. And therefore, that's a reasonable work that you can get done in this sprint. Once you've done, you can start your sprint and get to work on all those tickets. 20. Retrospective: The retrospective, also called retro road for short, happens at the end of a sprint. Here you review what worked well and what didn't work so well so that we can work out what we want to improve in the future. It's important to note here that this is a process meeting rather than a meeting about the work itself. So let's say that we had a ticket that we bought into sprint and then it turned out that it has a blocker. And so we couldn't do anything. It didn't get done inside that sprint. In the retro, we wouldn't talk about how to unblock that ticket so we can get it done. But we might talk about things like, well, how come we didn't realize that it had a blocker, therefore stalled. And what can we do in future to make sure we're not bringing tickets in that can't actually be completed in a sprint. So you probably comment on some of the tickets you worked on and what issues those bought. But we're not commenting directly on the work directly, but more about how we can work together as a team better in future to America team even faster and more efficient. You can do a retro any way you like. But I have some ideas for you in the next lesson. 21. Ideas for retrospectives: In this lesson, we'll look at some ideas for how to run your retrospectives. So this is really a starting point and you come up with your own ideas, do things creatively, have fun with it. One of the classics is Start, Stop, Continue. So give everyone in your team a marker pen and some post-its and put up on the wall or stop, start and continue. And people can write their suggestions for things we should stop doing, things we should start doing and things we should continue doing. So in this example, e.g. the suggestions are, will stop turning up to meetings late and having long discussions at stand-up. Maybe they're getting in the way. So next sprint, the team deliberately concentrates on stopping these behaviors than the mites, things that we want to start like, maybe retrospectives are always organized last minute and so booking a meeting room would be helpful, and then things continue. So we started using a new testing server for weeks ago when that's working really well. Let's, let's keep doing that. Another way to do it is to use scores. So you might have headings like, how confident are you going to deliver this project? How much energy do you feel we have as a team and how psychologically safety field and every team member can give a scoring number. It can be put up there anonymously. And then you can look at those numbers and you can chart your progress over time. So maybe do this every couple of months and see how it changes. But also if you notice, our confidence has gone really down or safety has gotten really down. What are we doing as a team that we can improve on? Maybe we'll talk more about that issue. Lean Coffee is a meeting type that works well in retro is also out of metros. And the way this happens is there's no prearranged agenda. So the first task is to create an agenda. And again, maybe, maybe give everyone post it. Some people write what they want to discuss down on a post-it, put it on a wall, and then the whole team can vote on an order for the discussion. So You talk like you pick the top five things you want to talk about, new timebox, each of those. So let's say the team wants to talk about the way we're doing stand-ups. First thing, you set a timer for 5 min and you have a discussion for five-minutes. And when the alarm goes off, then the team can vote to either say, we want to talk more about this, Let's keep talking about stand-ups. Or we want to move on to the next topic. And if the team votes to move on, then you pick up the second post it and you talk through that. And again, you do the same thing. He taught for 5 min. At the end of those five-minutes, you decide where this needs more time or you want to move on. And then finally, team-building. Not all retrospective has to be worked talk to get a team working cohesively. Things like Smalltalk, things like playing games, things like team-building activities can be really important to jailing that team together. So if the team is tired or if it isn't, it's quite challenging as you'd like, then doing some fun team-building and games can be really good as well. 22. Ways of working: Uh, ways of working meeting is the team agreeing on how they're going to work together. So each team is different and the members might want to work different ways for different teams. So questions like, Well, can you pick up any ticket from the backlog or does it have to be the top one? Do you assign it to the next person or do you leave it blank and leave it for them to pick up what's in our definition of done. When will the ceremonies take place and who will we invite? How long will Sprint be? All of these are process questions that the team needs to agree on. And you would discuss these all in a ways of working meeting. You would typically have to meeting when you're forming a new team and getting up and running. But also if a lot of team members leave and new members join, or it's just been awhile since you've had wound and you want to renegotiate some of the rules of the team, then calling a ways of working meeting is a really good way to do that. Keys to success is making sure that everyone has a voice and everyone gets to their opinion on what works and what doesn't, how they'd like to do things. And then to get everyone to agree on it so that everyone in the team really buys into that ways of working and everyone works together to support each other. 23. Sprint review: A review takes place at the end of a sprint or after it is finished. The purpose of the review is to review and demo the work that's been done. So everyone is invited, everyone from the Scrum team and also external stakeholders want to find out what the team has been doing as well. The team take it in turns to demo each of the features. And there can be questions from external stakeholders. We typically hold those until the end of the reviews that show everything and then allow some feedback. At this point, all the tickets are done. So if there's any changes, if there's anything additional work that comes up that should be raised as new tickets. 24. Scrum team: Scrum is all about teamwork and Scrum teams are cross-functional. What does that mean? Well, in the old days, the teams might be organized by job titles. So you'd have a team of designers over here, a team of engineers over here, a team of testers over here. And when you wanted something designing in, send it off to the design pool. And the design pool would work on everything and then pass it back. So anything that needed design for the whole company, we'd go to one specific design team. Scrum teams don't work at all like that. They are cross-functional in the Scrum team should have everything it needs. A Scrum team would have say, a designer and engineer, a tester, whatever goals may be a business analyst we needed in that, it's all contained in the team. So that rather than having to go to the designers, to the engineer's, to the text is everything you need is encapsulated within one team. So that teams kind of like a mobile unit in the military that can operate independently without getting blocked by other teams, without having to go. We need a tester for this, but there's no test is available. Everything is contained within the team. So that when we're trying to get through our sprint backlog, we're trying to deliver our tickets were not blocked by other people. 25. Product owner: The product owner is ultimately responsible for the product or project. So they're all about making decisions and priorities, about what the project is going to look like and how it's gonna work. So e.g. if we think about our e-commerce product page, what exactly is it going to look like? Where's going, where, what will the user experience feel like? And priorities as well, like what part of the system should be built first? Should it be the product page that check out the browsing? Which bit? Now, what it isn't is a technical roles. So when I say how it will work, that's very much a user experience thing. That imagining being the customer using this thing, rather than any technical knowledge. All of the technical knowledge will reside in the engineers and the product owner doesn't really need to know how it's implemented. They say what they want implemented. Now, each product should have one product owner. So if you've got, you're thinking about putting two product owners on the same product. You probably need to split that product out. But a product owner could look after multiple products. So if you've got a lot of little products than one product owner could look after multiple of them. What makes a good product owner was somebody who knows what they want, but he's also flexible when something can't be done. So e.g. let's say you're building a house. The product owner is the person who says, Okay, well, I'd like to bedrooms and bathrooms and garage. But then if Planning Commission come back and say, well, you can't have a garage, you want the product owner that's willing to say, okay, well, let's change that and I'll specify something else. But has a clear vision to give to the team, to give to the engineers about what they're looking for. 26. Scrum master: The Scrum Master helps the scrum team runs smoothly. So despite the name Master, they're actually another member of the team and they're on the same level. They're not the boss of the team. They organize and facilitate ceremonies, but at the request of the team. So it doesn't necessarily need to be done by the Scrum Master. Anyone can lead any of the ceremonies from any of the team members can step up and say, Well, I'm going to leave the retro, I'm going to leave the daily Scrum or if they prefer the ScrumMaster can do it. Typical jobs for a ScrumMaster might involve booking meeting rooms and facilitating the ceremonies, speaking to other people about blockers. So if the team needs to communicate with another team to resolve something to school masters, a good person to send there, representing the team at wider company meetings. We'll talk a bit more about that in scaling squirm. But really anytime where the team needs to go talk to management, needs to go talk to another group. The squamous is really good person to represent them as ensuring rules are adhered to. So if we agree something in a ways of working meeting like we're all going to be on time for our half nine Daily Scrum and people aren't turning up on time, then it's typically down to the schoolmaster to not tell them off but say, Hey, just a reminder. We agreed we'd all be there on half nine and none of you are also coaching and motivating the team. The scrum master typically has a good knowledge of Agile and Scrum and can bring in those recommendations as great ways of working into the team and getting a team fired up about the work that they're doing. 27. Business analysts: Business analysts, also known as BA for short, are involved in requirements gathering. Which team would typically have one or two BAs. And their job is to understand the user requirements and form a bridge between what the product owner wants and what the engineers need to know. Product owner might say something like, I want the ability for customers to track their deliveries and see where their deliveries are. The BA would go away and break that down into a customer journey. So e.g. the customer, as a customer, I want to be able to view my orders as a customer. I want to view the details of a specific order as a customer, I want to see the tracking information for whichever career the order is being sent on. And so they would take that product owners overall request, break it down into tickets, and develop acceptance criteria. So how will we know when it's done, e.g. if we're looking at a ticket as a customer, I want to see the tracking information. The acceptance criteria would be say, the customer can read the tracking number. The customer can click a link to go to the Careers website and found out more information. And maybe that's the acceptance criteria for that ticket. So the BA is responsible for translating those overall requirements into more specific requirements that the engineers can work with. 28. Engineers: The engineers or the people that work on the thing, whatever the thing is, whatever the project it is you're working on. So it's often called the Development Team, but it includes a wider field than this. So things like testers, automation engineer's, quality assurance engineers, all of these people would be included in it. And it really depends on what kind of project you're working on as to what this would include. In a software project, you'd have you'd have your actual software engineers and probably some test automation engineers. And then the test is themselves. But if you're working on, say, a research project, then you are engineers. The development team would actually be the research team or the researchers. If your project is building a house than it might be builders, laborers for men, that kind of thing. New in some ways it doesn't matter because in Scrum, there's a real focus on working together as a team to deliver tickets. So while you might have your individual roles of I'm a designer, I'm a software engineer, I'm a test or whatever it is, actually what really matters is the output of the team. So wherever everyone is sticking to their roles, are doing different things, are helping each other out. What's important is everyone's working together to that sprint goal to deliver those tickets and not so much focus to compartmentalizing everyone into this design team. This is implementation team, this is testing team. There is just one Scrum team of everyone contributing to the success of the project. 29. Stakeholders: Stakeholders are people outside of the team, but with an interest in the team's work. So what kind of people might not be? Well, some examples, our company managers, members of other teams working on related Project Solutions, Architects and technical architects at work across the company. Marketing and sales teams. Legal could be involved as well, and also potentially things like customers, suppliers and regulators would be stakeholders as well. Product owners would often invite stakeholders to the sprint reviews, and they're also welcome to come to the daily Scrum as well. But they wouldn't have any input on The Daily Scrum so they can come and listen, but it will be Scrum team members that did the talking. Stakeholders typically wouldn't be invited to sprint planning or retrospective because that's a safe zone for the team to discuss their workings internally. 30. A typical scrum team: Let's look at a typical scrum team. So inside of the team we've probably got a product owner, scrum master, and worn or more business analysts. So one product owner, scrum master, typically one or two business analysts. And then we've got engineers. Engineers covers really any of the doers. So kinda developers, designers, testing QA, researchers if you're working on a research project, and laborers, if you're building a house, whatever it is, those are the people doing the actual tickets. And then outside of the team you have stakeholders. So this could include company managers, members of other teams, marketing and sales legal, customers and suppliers, and regulators. 31. Adding team members: If you're adding members to your team, then how do you factor in that? The amount of work that they can do when planning for future sprints. Well, the first thing we wanna do is calculate our velocity and our points per team member. So let's say our velocity is 48, and there's currently six members in the team. Then we can divide 48 by six and we can see that each team member is producing approximately eight points. If we then adding a new team member, then we know that we're going to have another eight point to play with. So that means on the first sprint, we normally use a multiplier of zeros. So we assume that they're not going to put any points for the first sprint. Second sprint, we will have fit if it was eight points, will time's up by 0.5 and that'll give us four points. And then on the third sprint, we assume that they're up to speed and contributing, which means they can give all eight points to the team. 32. Issue types: In this lesson, we'll look at issue types or ticket types. And there's three primary ones. So the first is a user story. So this is a new piece of functionality written from the perspective of a user, of a product, e.g. as a user, I want to be able to see product reviews for the product I'm currently looking at. It adds something new to the system. Then we've got a defect or a book, a book with an existing feature that needs fixing. We've already sent out and it needs a fix. And so we need to raise a ticket. Now importantly here, It's only a bug if it doesn't work the way it was intended. So if we build something a certain way and the manager says, I want it to work a different way. That's not a defect, that's a new user story changing the way the system works. If the original ticket matches the acceptance criteria, then it's not a defect. If it doesn't do what it said on the original ticket then is and raise it as a bulk. And then we've got tech debt. So these are issues with the code that have no observable effect on the system. So something underneath that developer knows we need to fix, but actually a user wouldn't necessarily notice. 33. User stories: In Agile, we write tickets as user stories. That means that instead of having a ticket that says something like login form, we write something like as a customer, I want to check my order status. Now, often that would involve a login form so they can log in and see their orders, but it might not. So why do we write it in this weird user story format? What stories keep it focused on the user. So we're all about the customer journey of going through whatever it is we're building and writing in this way really keeps that focus on the end-user. Second, it prevents unnecessary work. So if you've got something like, I want to see my previous invoices, those that require a login form. In the next lesson, we'll look at a good case study that shows that maybe that isn't always the case. And therefore we can save ourselves some work if we use these user stories. It creates very clear acceptance criteria. If your ticket, it says login form. Well, how do you know if the user is able to achieve what they want to achieve? Do they want to login? What purpose does that give them? Whereas if it's something like I want to as a customer, I want to check my order status. It's very clear where V0 system does that or not. Can the customer see their order status? Yes or no? You got some really clear acceptance criteria there. And that's why we use user stories. 34. Behaviour-driven development case study: What we're talking about here when we write stories in this way is behavior-driven development. This is a methodology that says we write what the users should be able to do in plain English. And then that becomes our acceptance criteria. We write automated tests against that to see if the system is doing that. And let's say there's a huge amount of work and I've got a case study for you. So there was an accounting firm and what they wanted wars for customers to be able to view previous invoices. Now if we just jumped into that and kind of built it the normal way, we'd have said, Well, okay, we need a login form and each customer needs a login, so they need to put her e-mail address in and then they need a password. And so the customer, we'd have yet another password to remember in this sea of thousands of passwords and they probably forget it. So then we'd need to build a forgotten password link that would e-mail them a new password. So when they inevitably forgot their password, they could request a new one. They could reset their password and then they could login and see that old invoices. Instead, this product use this user stories and behavior-driven development. So the acceptance criteria was as a customer, I want to view previous invoices. Then when the project looked at it that way, they realized that the simplest thing to do was to allow the customer to input their email address. And it would e-mail them a magic link that would allow them to see all of their previous invoices. So rather than having to build all of the login form and Forgot Password form, rather than the user having to remember another password by looking at it from this user story angle, everyone realized that actually the quickest way to do it is to just email them a link that will allow them to access it. And it's just as secure as having a login because you've got the e-mail access and then they can view all of their previous invoices without a load of development work and without the user having to store another password. Using these user stories, using this behavior-driven development approach can save a huge amount of time and it can produce a better experience for the customer as well. 35. Being "good enough": A key concept here is the idea of something being good enough. We need to build the feature until it matches the user requirements, the acceptance criteria. And then we need to stop and close that ticket. And if we need to do more work later, we can raise a new ticket. But basically, what we try to fulfill, what needs fulfilling that, assuming that we need all of this extra stuff. So e.g. let's say we are talking about we've got our e-commerce store and you can view the products page and we want to show similar products. And maybe the user story is, as a user, I want to see similar products to this. Well, we could go off and we could build a massively complex AI system that recommends products. But we could also just put over products that are in the same category there that would fulfill the user requirement. And we wouldn't end up with a massive development task because maybe just showing the similar products and the same category would actually be great. And we can ship that really quickly and that would work. We wouldn't really get any benefit from building a huge AI system to recommend products. Or maybe we ship the easy thing. And then we realize actually we would get a ton of value from having better product recommendations. Which point we can build the better thing, because we know then that it's worth investing the time. This is what's known as Lean methodology. So you get something out there in our basic form. You see for users like it, you see what they respond to, and then you re-evaluate and you go again, just as we've talked about this agile methodologies, you've iterating, delivering something, saying how it works, improving it, rather than building this huge big bang product that might fail from the start. 36. INVEST: In this lesson, we'll look at the invest acronym that can be used for good user stories. So I is for each independent, each store it should stand on its own and is negotiable. Stories are not fixed but can be updated if required. So bringing that input in and things like even when you start implementation, if something can't be done because of technical requirements, it's frustrating, but maybe you need to look at how you rework the story. If that's the case, V is for valuable, it needs to add genuine value for the user. How is the user going to get a better experience because of this change? E is for estimatable. So you need to have a rough idea of how long it will take. If you can't estimate it, then what you probably need to do is raised and investigation ticket. A ticket that's like as a developer, I want to investigate how long it would take to implement this feature. And then timebox that to say half a day and see if you can work out a rough timescale. And then based on that timescale, you'll know whether you want to move ahead with the ticket or not. S is for small, so it can be delivered within a single sprint. Anything that's taking multiple sprints needs to be broken down further. And T is testable. Clear acceptance criteria, how would a user know if this ticket was complete? And ideally, we've automated testing as well. So really thinking about how we can test it in automatic test coverage kind of way from the start. 37. Prototyping and user labs: A co-operative bowl of both Agile and Lean is to build it quickly, build something, basically, get it in front of the user and see how that works. Now a good way to do this is with prototyping. So you can use something like Adobe XD to build mock user interfaces. And then you can give that to a user. See how they use the system, see how they get on with, make some changes before you build the complicated piece of software themselves. How do you do this? Well, you mock it up in something like Adobe XD. And then you'd ask a sample user to come in maybe to a lab. You'd film them, film the screen. Go watch them as they're doing it and just take notes of, okay, what works for them. Engage in a dialogue with them, say, Okay, well, Okay, I'd like you to find this product. How would you go about it? Are they going to go browse and they're gonna go search and they're going to view that order history to see if they have previously bought it and they can find the link that way. Which method is going to be best for them. You give them the demo, you ask them to do the task. You talk to them about where they're thinking about going get them to talk you through, okay? I've said, try and find this product. What are you thinking about now? And the user might say, Oh, well, I probably use a search, and search is my favorite way to do it. And then they could search and come up. And that way, we know exactly how a user wants the system to work, and whether it's wherever we can build that system and whether we can adapt it to their needs. Now, a lot of this is time-consuming, but asking someone to come into your office, setting up a lab where you can fill in what's going on or have watching and given them a set of tasks. It does all take time, but that time really pays it back when you deliver something that's exactly on what the client wants. If you can see how they use the system, optimize it around them and really get that feedback from day one. It takes a lot of time initially, but then your development time is way smaller because you're building exactly what they want. Whereas traditional systems, you'd do the big development block. Then it turned out that it wasn't actually what they wanted and we have to re-engineer the whole thing by investing that time early. We can then build exactly what the user wants and deliver that functionality faster. That's right, exactly what they need to do. And we can do that by things like rapid prototyping and user labs. 38. Functional requirements: Functional requirements tell you what the system should be able to do. E.g. if we say trying to check our order status, the functional requirement might be the user can see the status and the other customers can't see the specific customers order. Or if we're building a login system, e.g. is it via password, is it via e-mail, is it via two-factor authentication? And how are the passwords? Reset? So is there a reset mechanism? Maybe the users should be able to, should be prompted to change their password every 90 days. All of these things are functional requirements because functional requirements document the functions of the system. They document how the system works. Not slightly different to non-functional requirements. And when I go on to discuss those, I think you'll be able to see the difference of which one is which. 39. Non-functional requirements: Non-functional requirements are things that are important or essential, but don't directly affect how the system works. So what kind of things might this be? Well, things like performance, how fast does the system respond? Availability and scaling to high load? Is the service always going to be available as security monitoring? So how will you know if something breaks reporting? Can we ask the the back-end? Can we see what's going on? Accessibility and usability? Those probably more functional requirements now, it's really important for those and then documentation. How will future developers or the system users know how it works? So note that these things aren't optional, right? Like security and accessibility are legal requirements because our projects have to be accessible. And if we don't have enough security, we're going to violate GDPR law. So the things, these things aren't optional extras they all need including, but they're not actually part of how the system works. So e.g. if you have an order status page that shows a customer where their delivery is, that's the functional requirement there is that the page tells them where their delivery is. But there's a bunch of non-functional requirements so as well. So e.g. how fast does a page take to load? Well, it could take, wouldn't second or 1 min. Now if it takes 1 min, users are gonna get really annoyed and they're probably going to leave and go shop somewhere else. But technically, if it displays it that meets the acceptance criteria of user can see the order status. So it's not technically a functional requirement, but it is really important. Similarly, security if someone else can see their order status, that doesn't necessarily violate the functional requirements. But it would be really important because we'd have exposing private data to someone that shouldn't have access to it. So it's really important that we think about non-functional requirements as well as functional requirements. But they're easy to forget. Forgotten about you build a feature and you forget to run it through the security testing or the accessibility testing and F or something gets messed. That's why it's really important to include these non-functional requirements in the definition done. So don't allow a ticket to be moved into the done column unless it has monitoring in place, unless it's been tested for usability, unless it's been tested performance. But all of those things in your definition of done and then, you know, to test against them so that you know, everything that goes into it don't call them meets the functional and non-functional requirements. 40. Tech debt: There is one type of ticket that an engineer might raise and that is tech debt or technical debt. So this occurs when we do something to speed up delivery, knowing that we're going to have to address it later. E.g. let's say we're building some software that's maybe it's like a weather app. What pulling whether in weather data in from an external source. And we've been using library a. But now we need to use library be because it's better or allows us to do something and we just want to switch over to library B. Will a really quick way to do that would be to bring library B into our application without removing library a like that was still fulfill the requirements if we will now using library B, even though library a was still embedded or brought into the codebase somehow. Now if we did that, that would generate some tech debt. Because library a still needs removing at some point, we just haven't done it yet. Now why is it important to tackle tech debt? Well, one, it makes the code a lot easier to read if you're new to the project and you're thinking, Oh, why we using library be, but we've also got Library a in there. What's going on there? That can be really confusing and therefore, it's harder to onboard people. It's harder to do future development work. It can slow down things like the build process. So when we're compiling the software, if we're bringing in two libraries, that's going to make it, it's going to make it bigger than it needs to be in slow it down there. Or it could affect performance, e.g. if it was a client-side JavaScript library. And we are bringing in library a, library B, but only using library be. Then we'd be loading library a into the user's browser without any need for it. So it has a lot of non-functional effects, even if it doesn't necessarily affect the function of the software. And that's technical debt and why it's important to tackle it. 41. Cancelling a sprint: On rare occasions, the requirements for the project might change mid sprint. We have this principle of Scrum of nothing new coming into a sprint. So we define the tasks we want to do at the start of the sprint and then we start the sprint and we do them. And we don't bring more tickets in until the next sprint. So what do we do if whatever we're working on becomes irrelevant and we don't need to fulfill the sprint goals anymore. Well, in such occasions we can cancel a sprint and the product owner has the authority to cancel the sprint. They think the requirements have changed and there's no point continuing to work on what we're working on. They can go ahead and cancel the sprint. Any tickets that were working on, then go back into the product backlog and we form a new sprint. So we have a new sprint planning meeting. We work out when our newsprint is going to be and we bring in data tickets on new tickets to match the new requirements. 42. What is agile release management?: When we talk about Agile, we're talking about small iterations, small little features that we build, that we get ready and then improve on them. Now some organizations embrace this idea of working Agile, but actually deployments are still done in a Big Bang way. So there's all these Agile teams working on features for a software, but then the software only ships every two months and there's all of the features are released at the same time. So when we're talking about Agile Release Management, we're talking about getting rid of that big bang release. I'm replacing it with a more iterative cycle, some more in line with the development work that we're doing in sprint, in sprints and in the Scrum teams. So the idea is that you might get a set of features and you might release those independent of features that other teams are working on. So say team a, build some features and deploys that and team-based build some features and they deployed separately. We might even be talking about individual tickets. So TMA finishes one tick in as part of that finishing, it's merging into the main code base and deploying it, and deploying those issues one at a time. Whatever way they exact way of Agile Release Management ends up being implemented. It's all about reducing that development cycle, that lifecycle of software, so that we can get small pieces of functionality out without having these big bang releases where we push loads of features out at the same time and don't do many releases and said we want regular small releases in line with the Agile process. 43. Release management cycle: All development goes through a cycle. And in this case we're going to look at the release management cycle. So you can start really any point, but we'll start at the top with requests for changes. The product owner wants something changed. And so we design a solution, we create some acceptance criteria that would implement that change. We then build it and we write the code and then we send that off to someone else for review so they can check that the code makes sense and is a good idea. We then test it to make sure it works and if it passes, that will then deploy that piece of code. We'll then have some kind of metrics are reports on its performance. And if there's any problems, then we'll do we'll report some issues. We'll work together as a team to raise a defect or raise another user story to change it. And then that feeds back into the request for changes. 44. Advantages of agile release management: Why would we want to do Agile releases? Well, here's for real advantages of the Agile release process. Number one is that it gets things out faster. So we're all about shortening that cycle of development. So you build a feature, you push it out straight away, you can start getting feedback on it immediately. If it's an important change, it's gonna get out faster, the bundling into a bigger release down the road. Number two, it works in line with Agile. So if you've got all these Scrum teams working in this very agile way, why would your release process not support that? Why would we suddenly go back to the big bang approach, which has all of its risks of failure. Number three, it allows the scrum team to take responsibility for the release. So in the old way, all the teams would develop stuff and then some of the team would have to take responsibility for releasing it and looking at bugs and monitoring the impact of fruit has been released. When you give it back to an Agile process where each team could release the features they've been working on. Then the scrum team can take responsibility for all of that. They can push out the features, they can monitor what's happening. They can do a rollback if needed. If there's worst-case scenario, there's some problems and they need to do that. But it fits in line with this idea that Scrum teams are independent units, cross-functional. They take responsibility to the ticket from start to finish, and they can guide the whole process without being blocked by other teams. And number four, it can be safer. So there's this kind of old school mentality of the idea. As you build all these features, you give it to your testers and your text is when all these scenarios on it to make sure everything works together. But the reality is when you release 100 features from ten different teams at the same time, they're probably going to interact in ways that you didn't imagine and you're very likely to have things go wrong. And when things do go wrong, it's a real pain to roll back because you're rolling back 100 features from ten teams. When you allow these really small iterative releases. Then if a release goes wrong, it's really easy to roll back because you only change one thing. And the team that changed it is managing the release so they're able to roll back really quickly. I would argue that Agile Release Management is not only faster and better, but it's also safer as well. 45. Common release schedules: Let's look at some common release schedules. Them all. Oldest style would be what we call a Big Bang release. So it's a large release for multiple teams and a large test team to review all the features. So this is the kind of, let's say you've got three different teams working on a product. You're, you're working on like Microsoft Windows nine and you want to release Microsoft Windows ten. So all of the teams working on that put all of their changes in and you release it. Big Bang thing that's Windows ten has all of the changes in at once. And you need a huge test team to review all the features because everyone is putting in these changes and it's not clear how they will interact or how things will break because you need to retest everything. And so it's really slow. Then we've got something like a sprint. So here we're getting into our more agile release process. So one release at the end of each sprint. It's nice because it has a very predictable release schedule. And what's the point? Like, you might have some splints where you have lots to release and you have some sprints where you don't have much to release. And so you probably want to get this stuff when you're producing loads of stuff that can go out, you probably want to get it out faster. And when you are producing not so much stuff that needs to be sent out, then why would you, why would you release? So it creates a bit of flexibility there. Moving down, then we've got this idea of feature release. So manually released, each feature is it's ready. So the scrum team will get a feature ready. Then you will manually merge that into the codebase and get that released. Fast. Small changes. It's nice and easy to roll back. There is some management required, like it is a manual release process. But this is even in the Agile world who have companies that have really embraced Agile feature releasing is still really popular because it gets you that fast, small changes without having the risks of continuous, which we'll talk about next. So continuous is where every change soon as you merge something in, it just gets pushed out to your production server. Um, so it's super-fast, very easy to roll back because you're pushing out a single commit. And so when you're rolling stuff back, the only thing you need to consider is the latest commit gets a bit tricky if you only realize it that it's broken down the line. And then maybe you have to have multiple commits back. But if you're just releasing one, testing, if it works on production and then moving on and can move really fast. But it does require a really high level of test coverage because literally everything is going to be pushed out and so it could break at anytime. And you really need that high level of test coverage to make sure that everything is working. 46. Keys to success: Here's some keys to success for Agile Release Management. Number one is to get buy-in from management. This goes for basically everything you ever do. If you can get management on board, you're going to have a much easier time. And as we discussed previously, there's some kind of old school management that prefers a big bang releases because they think they're safer. And so I tend to focus on really selling them on this idea of actually if we make these really small releases that we can roll back really easily. And that would just rolling out one thing at a time so we know how it interacts with everything else. It's safer. So not only are we going to get your features quicker, but will also make it so that things go wrong less often. Number two is to design features with deployment in mind. So when you're building a feature, how are you going to get this out? A great example is things like feature switches. So you can deploy the code if you put it behind the features switch and then switch it on at a later date. So deploy the code, switch the feature on. If it doesn't work, you just switch it off straight away and you don't have to panic. And if you can think ahead to what are the steps I would need to deploy this ticket, then you're going to find it much easier to make those releases. Number three is have a good rollback plan. If something goes wrong, can you roll back really quickly? Traditionally, in waterfall methodology, we haven't had a great method for doing that, but it's much easier when we're doing these really small releases and builds a lot of confidence if even when things do go wrong, you just type in this little command. It rolls at the whole back automatically and everything is fine. Number four, have high automated test coverage. So you want to make sure that after you make it to change, then you can run all of the customer journey is all of the scenarios you need to do automatically using all of the automated testing tools out there. Because when you're doing really small releases, then you're going to want to be testing constantly. You make a change, you test everything and make a change, test everything. The only way to cover that is with automated testing because you couldn't have enough testers to do all of those scenarios. So if you get that test coverage, that gives a lot of confidence to you and to management that things are going to work. And number five, coordinate with other teams. Make sure you know what other teams are doing and how they might interact with you. And also in terms of scheduling a Ukrainian released this morning, are they doing and releases morning, how are you going to q when he can take it in turns to do these releases, so you can get things out quickly and efficiently. And so you're not going to tread on each other's toes. 47. Continuous integration: Continuous integration runs the automated tests after every commit. So it could be every time a developer pushes up some code, it runs it, or it could be every time a ticket is merged into a master, you want to run it on those branches depending on how much you want to spend on your continuous integration tools. Now I'll show you an example here using Travis, which is just one of the options available. And I've got this project here, which is an open-source learning environment. And I've defined a config file here just to tell the continuous integration server that it's written in PHP. And I wanted to test it again, sudden point 4.8, 0.0. And here's all the steps you need to set it up. So that means that when I push up a commit, it's going to run the tasks against both PHP and PHP 7.01. We can go into these and see what's happened. Travis has established everything. It's run the installation as a requested and then it's run PHP unit to execute the tests and it's passed. So that's great. And then it's done exactly the same thing here, but it's running again, 7.4. So if you have multiple different production set-ups, you can have the continuous integration server test against all of these setups. And I can see a full history as well. So if I go to Build history, this will show every time I've pushed up a commit, it's done a build. And e.g. here, we had one that failed build. So we can go in and we can't see the logs anymore unfortunately, but we know that something went wrong there. And then I fix something else here. So in this case it was changing the PHP version to match the server. And we can see the build is working again. So it's really easy to trace down. You can run the automated tests against a variety of environments and you can really easily see what's gone wrong because you can see exactly where the build stopped working. 48. Continuous delivery: A step on from continuous integration is continuous delivery. So here the code automatically passes all of the automated tests and it's automatically deployed to your production environment. Now this doesn't mean that you're deploying every single commit. So there's several branching strategies. You could use it, you could have it so that you have a production branch. And every time you merge something from master into production, it runs all of the automate tasks. And if that works, they go up without any further human intervention. Or you can have it where Master is sitting on your production environment. And every time a team merges and individual ticket into master, it runs all the tests and it deploys automatically. What it is, is taking away from the idea of manual deployment. So a ticket can merge a piece of feature in all of the tests are run automatically and if it's fine and gets pushed up to the production environment. 49. Continuous delivery tools: There's a big selection of different build servers and continuous integration tools out there. In this lesson, we'll discuss a few of them. The first one to mention is probably Jenkins. So this is an open source automation server. So you need to host this yourself. You need to have a server in your organization and run Jenkins yourself. But it is open source, it's free and you can run it in-house. Then we've got the hosted environments that typically plug into. If you've got something like a GitHub repo, it will plug into that and pull your code from there. So we've got Travis CI, which I showed you the example from. And then we've also got a CircleCI. And if you'd rather keep things on GitHub, then GitHub actually has a thing called GitHub Actions, which allows you to do CI, CD processes and obviously hooks in really nicely if your repository is there or you can use a platform like Get lamp. This is kind of like a continuous integration server and get hub built into one. So it's both for Git server and it will build your software for you as well. And then Team City is another continuous integration server that's very popular as well. 50. Agile software: So far, we've mostly done things with spreadsheets and post it. And this is a great way to learn the fundamentals and understand how the systems work. But in a business context, a lot of this stuff is normally done using project management software. And this is really good, especially if you've got a remote team where people are all over the place and they all need to be able to see the board and son where the tickets are. And you've got everyone collaborating together. This is where the project management software really comes into its own. And so in this module, we're going to explore some of these solutions are already available out there for you to use. 51. Jira: Jira is possibly the most popular tool for doing scrum online. So let's go ahead and create a project here. We'll call it e-commerce store. And we'll change our template here to scrub. Perfect. Yeah, looks good. We'll go ahead and create that. I'm going to skip having any tools for now. Okay, great. So we've got our backlog here. So under this here we've got our roadmap. Here, we've got a backlog so we can start adding issues to the backlog if we want. Or we could start adding things as well. So here this product page is kind of like an epic. And I'm going to say as a visitor, want to see the product title. As a visitor, I want to see a picture of the product. As a visit. I want to read the products reviews. Then we could add another epoch here. So we could say Management Portal. And then as a manager, I want to see the list of orders. And as a manager, I want to dispatch and order. This roadmap tab allows ups. I have created those epics instead. And it would help if I could spell. We go dispatch and order. Great. Then that's probably not going to let us delete these, but let's try. There we go. So we can go into each of these and we can add a description. And then we can add some story points here. So maybe lots of one. Let's say that's three. And this one is five. This one is gonna be a two. And this one's going to be a five as well. Great, So we've got some points values there. And if we've got a backlog, we can start organizing these into sprints. So here we've got our first sprint. And we can drag some of these tickets n. So we've got our product page tickets n, we've left those in the backlog. And if we hit Start Sprint than this, we're now on the board tab. And here we've got our board. So we could add some columns here if we want. We could call this code review. I'll put that there. And we'll add one for testing as well. Stick that in there. Then if I want to start on a ticket, I can assign it to myself. I can send it into in-progress. And here we've got our board all as we update all of these tickets, you will update for everyone. And obviously as we invite our team members, then they'll be able to see the tickets moving across the board as we move them as well. 52. Burndown chart: So a key metric you want to look at in your sprint is the Burndown Chart. So if we click this Insights button here, we can see we've got this sprint progress that tells us what percentage is done is in progress or not started. And we've also got this Sprint Burndown Chart here. So I defined it as a two-week sprint. And we can see in theory, we should be completing these number of points. So halfway through, we should be like halfway through the points. So as we, as we move these tickets in, just update that we can now say 100% in progress, but nothing has been done yet. But then if I take one of these tickets and move it to Done. And again, we'll refresh. Now we're at, now we're at 56 per cent done, 44% incomplete. And we can see our burndown chart looks really good because we want this blue line, which is the work done to get down to zero before here. And so we'd need to be hitting this line in order to achieve it. If it's up here, then we're not getting through the work as fast as we thought we would. If it's down here, then we're getting through the work faster than we thought we would. 53. Trello: Trello is a really simple tool for creating boards and to-do lists. So I've got a brand new board here and we can add any columns we want to this and maybe we add an in-progress. If I can spell. And then a code review, testing and done. And then I can start adding things here. So I want to see the product name. As a visitor, I want to see a picture of the product. Say visitor. I want to read the products reviews. And then these, we can click into them. I can assign them to me, e.g. I. Can add a description, so save that. And then my little pictures because I signed it, I can move that into in-progress. Now, what Trello won't do because Trello is super simple to get started with. That's it. We're on a roll now. It won't give us all the reports that some of the more advanced tools will do. But it's great for small projects, simple projects or projects where you just want to keep going, get going and you don't want to spend too much time messing about because you can easily create these little boards, share them with your team, and get everyone working really rapidly. 54. Mural: Here's another tool called Miro, and this has loads of templates. So when you first load it up and we'll just have, you can use these bonds friend hanging. But if you go to Agile, it's got loads of cool things. So e.g. it's got a retrospective template, Start, Stop, Continue retrospective. Bunch of the things we've talked about. Or we can go down to five whys worksheet, really good for warships, team retrospective, daily squirm. And it will draw up a board view. And then again, likely orbitals. You can share it with all of your team members and then just start, start using it. 55. Building psychological safety: Psychological safety is about whether team members feel like they have the confidence to safety, to express their thoughts and ideas. And it's really a team's responsibility to build this. Because unfortunately, many of us have had the experience where we don't want to speak up. We don't want to share ideas because we're worried. We'll get judged, we've got shouted out, we'll get fired, whatever it is. Those are not psychologically safe environments. And in Scrum, we recognize that every member of the team has something really valuable to introduce them, to comment on them. So if we can build psychological safety so that more shy or team members, or indeed any team members can really be honest about their feelings or opinions, then that's really beneficial. So how do we build psychological safety? Well, establishing it verbally and in ways of working is really good way of just pointing out that everyone's opinion is valid. So having that written down and having that all agreeing as a team that we really want that input and that we're not gonna be judgmental. We're going to listen and respect everyone's opinion, goes a long way to building that safety. Good rules to have might include, it's okay to make mistakes. If we have a culture of judgment and blame than people are not going to admit their mistakes and therefore we're not going to learn anything. Whereas if we establish a culture where we don't blame people for mistakes, we just look at what went wrong and how we could make sure it doesn't happen again, then people are more likely to be honest. And therefore, we can fix these problems. Having everyone's input is valuable, is just having that as a rule of saying, a lot of people might feel like their opinion isn't important. And so if the team all agrees that everyone's opinion is important, that can really bolster some people to being more open. Having a culture of respect, to respect tampons idea and having no interrupting. We've probably all been in those meetings where one person just keeps interrupting and it's really annoying, it's rude and it's disrespectful. And the person getting interrupted will eventually just give up and not share their ideas. So if we establish this idea that when someone's talking, we don't interrupt them, which should be basic manners, but often we need a bit of reminding. Then that can be a really useful tool to one of the ways that we can build this is to ensure that there are regular retrospectives to ensure people have their say and people can talk about how they think it's going and how confident they're feeling in the team. And it can be really good to take these off site. So if you've got an office here, maybe you've got a coffee shop here. It can be really good to go into that coffee shop or go somewhere else. Just take it away from the office of people feel like in the office that's clearly like the managers domain. And we might feel a bit more nervous that you take that out into a more relaxed environment like a coffee shop can really help people open up too. 56. Wash-up meetings: Worship meetings happen after a project is complete, but also probably more importantly after something goes wrong. This is a time when people are worried about blame. So the point of the meeting is really to work out what happened and what can we do better next time. So really important to stress that it's not an investigation as in trying to find some people to blame and punish them for it, but just understand what's happened and where we can fix it. So the next time we can do better. Now really good tool in worship meetings is to use what's called the Five Whys. So we just ask why five times. And the more we do that, the more we get to the root cause of the problem. So let's say something like we've had a server failure and the teams got together for a wash up meeting. And we might say, why did the server fail? When, why? Well, it ran out of disk space. Okay. Why did it run out of disk space? Well, the lungs filled it up and there were so many logs that it filled the entire hard drive. So why did the server get filled up with logs? Well, there was no monitor setup on the server to alert us when the hard drive got to 80 per cent full. Why was there no monitor setup? Well, it wasn't in our definition of done when we were creating the server, so we forgot to do it. Why wasn't in our definition of done? Well, we never had a ways of working meeting for the team to work that out. So we can see when we ask all these why questions and we keep digging, we keep digging a problem that might look like at first it was an individual's fall. It was somebody let the server fail. Actually, at the root cause of it. It's a team issue and something we can do better next time. We can have the ways of working. We can improve our definition of done. We can go back and look at it, improved monitoring. All of these things came up because we kept asking why to get to the root of the problem rather than thinking about blame. The key point about worship meeting is really talking. We talked about psychological safety, building that environment. Well, we're not blaming, we're just looking at what went wrong so we know what we can change in the future. 57. Selling agile to management: Agile might sound great, too many of us, but management and not always on board with it. So how do we convince them that it's a better way of doing things? Well, first, we should consider what worries, what concerns management might have. One, it's a change. Change can be scary. It's a different way to the way they've done things before. And so if a company has been successful or it's been at least coping so far, then changes. There's always an element of risk in there. It might seem like it takes ages to do anything rather than the kind of old waterfall method, which is efficient if it works perfectly. Nephron does work perfectly of course, but hypothetically could, whereas we're selling management and ideas. Okay, Well, we're going to build a blank product page. Then we're going to put a title on it. Then we're going to put an image on it and we're going to be releasing and showcasing and reviewing all of these things in this step, you might sound like it's going to take ages. And it also empowers teams rather than managers. And that's scary if you're a manager and you're used to micro-managing and being in control over everything. And then someone comes along and said, we've got this scrum methodology and it's really good to empower the team to do the work, then they can might be nervous about that because they like being controlled. So how do we address these fears, these concerns? Number one is a document expensive failures and slow approval processes. So if there is say, let say the big bang releases and it goes along and it takes hours to roll it back. And there's all sorts of complaints, then that's a great thing to document. Or if this slow approval processes where you like you roll out a feature and it takes two weeks. And the product terms is asking, where is it, where is it? And you're saying, well, it will go out the next release, but we do company-wide releases so we can't do anything you'll feature is gonna be to eat late. And then we miss a deadline document, all of that. Because if you can go to management and say, Look, here was a massive failure because we did the big bang releases. Here we missed an important deadline to get something changed because we had to wait until the next release. That's good evidence that the process that's in place currently isn't working. Number to focus on the benefits of quicker delivery, managers generally like to get things out there as soon as possible. And so if we can tell them, look, this feature that you asked for, it took eight weeks to do. Then there was another two weeks waiting for a relief. And actually we think we can get a basic version out of this half that time, including the release. We won't even have to wait till the next release. That's gonna be a big selling point. And we talked about earlier also bring in this idea of safety. This idea if we're doing small releases, easier to roll back, we're going to have less of these catastrophic failures. Number three is talk about happier teams. Generally teams much prefer to work in an agile way rather than the waterfall way. In a waterfall way, the team isn't really in control. It works on one part of the system. It doesn't take responsibility for it. It doesn't see it through, doesn't empower the team. Squanders all the opposite of that. It completely empowers the team to take responsibility for what they're building and how they're going to deliver it. And people love that teams loved that, they love that. The company is trusting them with that responsibility. And then they're able to do that job and they're able to do it well. And that means happier teams. And from a management perspective, that means reduced turnover. People are not going to leave because they're going to enjoy their job more and so they're going to stay with the company. Number four is to acknowledge that change is scary. They might be worried about all these things and we can say, Well, yeah, those are concerns. We're pretty sure when 99% certain that squirm is better than waterfall because everyone is going on these days. But why don't we do as a trial. And a trial is a great way to get round objections because if you say, Okay, let's let's try this for three months or six months and see how it works. And if everything explodes, we'll get back to waterfall. But if it works and we can expand and roll it out across all of the teams, then you're much more likely to get buy-in because that will try it. And it's less risky because it's only a temporary thing. But of course then we'll try it. Who work really well. They will love it and we'll be able to roll it out across the entire organization. 58. Coaching good practice: We mentioned this idea that sometimes we need to coach best-practice and encourage your team to really use all of the framework that's available in scrubs. So how do we do that? How do we coach effectively? Well, number one is to start where the team is now and see what works for them. So there's sometimes a tendency to walk in and just trying to start make changes. But if we do that, the team would probably going to be quite oppositional. And they're happy with the way things are. If we go in, see what works, see what doesn't work. And we can observe, we can ask questions and then we can see what it's not quite working for them. And at that point, then we can start suggesting change and say, I noticed this isn't working for you. How about if we try it this way, maybe that would help solve the problem. Make suggestions, not commands. People generally don't like being told what to do. So as we just discussed, if we can make suggestions and offer it to the team, they can choose to embrace it. They can choose not to embrace it. If they feel in control of the changes, they're going to be far more on board with making them than if we try and impose something on them. Use how or what questions rather than why we ask someone, why do you do it that way? It sounds quite accusatory. And that puts people on the defensive. If we use how or what questions like, okay, well, how do you do that and what's that like? How's that working out for you? Then you get people to be a bit more examining of the situation rather than being on the defensive as they can be with why questions. Remember that squirming ArcGIS is not a religion. So focus what works, take him what works, and you don't have to use what doesn't. If something's not quite working for you within the Scrum framework, don't use that bit, used the bits that work for you in your organization, in your team, whatever it is, take the good stuff in and don't be too dogmatic about the rules. Be a role model. The most important things we can do is follow best practice ourselves. If we're not following it, then we can't expect other people to follow it. So if there are areas where we think that maybe we're not quite in line with how we see best-practice, then nudging ourselves onto that course so that we're role modeling what good practice looks like. And also when people see it working for us, then I don't think it's working working for Chris, maybe I'll adopt that as well. See the bigger picture teams are within organizations. So sometimes the team will be doing something a certain way and there's a better way to do it. But sometimes that is the best way to do it within the organizational structure they're contained in. So it's important to consider how the wider organization values might affect the team and lead them to do things a certain way. And then try changes as an experiment. So change can be scary, but if we sell it as an experiment, why don't we just try this for the next two sprints and see how it works. People are much more likely to engage in that because they don't think they're committing to a permanent change digits. Okay, we're going to try it for Sprint. Two sprints are a couple of months, whatever it is, if you're trying to swim in general, you probably want to commit to a larger timescale, maybe three to six months, at least, something like that. But if you phrase it as an experiment, Let's try this and we can go back to the old way. If it isn't working, people will be much more relaxed about trying things than if you say, right, we need to switch over now. That sounds very permanent and very scary when we say, let's try it as an experiment and see if it works or doesn't work. People are much more likely to engage. 59. How to scale Scrum: Scrum is designed for a team of around ten people anymore than this in the team and it starts to become unmanageable. You can't get everything done in a daily scrum. And the meaning, the updates are less meaningful because the people over here and the people over here, I'll probably working on different things. And so the updates don't really work and it's not as much of a team environment. But what happens if you've got a project that needs more than around ten people working on it as we often do in business. Well, in that case you need multiple Scrum teams. But the concern areas, what happens if the scrum team start treading on each other's toes and getting in each other's ways. How do we scale up from a single Scrum team to multiple Scrum teams? Well, that's what we're going to look at in this module. 60. Scrum of Scrums: If we have multiple Scrum teams and they need to be able to communicate to stop them treading on each other's toes. So how do we make this happen? Well, one solution is Scrum of Scrums. So this is essentially a daily scrum. So the same thing as the daily Scrum. But each Scrum team sends one delicate and that forms is kinda greater Scrum of Scrums. So it could be done daily, could also be done weekly if that works in your organization or whatever frequency works for you. But it's the same format as a daily scrum. Each swimming is represented by one person, and that could be anyone. So it could be the Scrum Master, if that makes sense, could be, say, a lead engineer, but really could be anyone. You could rotate round the team so everyone gets a turn going to the Scrum of Scrums and seeing how it works. When you're in the Scrum of Scrum itself, it works like the daily scrums. So question to ask is, What have we done? Especially stuff that might be impacting other teams? What are we doing right now that might affect over Teams and what blockers could other teams help us with. So in the same way that when we're doing our daily scrum, we'd speak about what we individually done previously, doing right now and what blockers we've got, we are coming to the Scrum of Scrums and saying for our team, this is what we've done, this is what we're working on. These are blockers that we need help with. Every team feeds in so that the teams know what each of us working on. And then the delegate goes back to their individual Scrum team and feed back and irrelevant information to the rest of that team. 61. Splitting products: A key concept in Scrum is one product has one product owner. You can't have one product. We have multiple product owners. What happens if you've got to Scrum teams need to work on the same project. Sounds like you will have two different product owners want in each team working on the same product. How do you deal with that? Well, in that case, we need to split the products somehow into separate sections. So let's bring in our e-commerce site again, as an example. It's a big fight and we want to different scrum teams to work on it. But we can't have two product owners owning the e-commerce site. What we could do, e.g. is split it into front-end and back-end. So by front-end domain, the things that the customer will see if they're coming to the site to browse. And then the back-end system is the things that the warehouse staff and the sales team working for the e-commerce site use to manage and dispatch all of the orders. By separating those out, then you can have one Scrum team taking responsibility for each. So you can have Scrum team working on the customer-facing side. Scrum team be working on the back-end of the product and you'll have a product owner for each managing those. Now another solution you could do is have one product owner working across multiple Scrum teams. So team a is working on front end, team B is working on the back-end. And there's one product owner who manages and works across both teams, makes for quite a busy product owner. But depending on how much decisions and how much autonomy it's team has, that can work quite well as well. 62. Sprint alignment: If you have multiple Scrum teams, then you might want to start thinking about sprint alignment. So if you've got team a and team B or their sprints going to start at the same time? Are they going to be different? The time having them work at the same time works quite well because if you've got some blockers like TMA is blocked by something Team B's working on. The team began work on this and say sprint free and team a nose that they'll be able to pick it up in sprint four, shimming, it's been finished. And so everything is aligned. You can get your product roadmaps aligned. So you can say, well roughly, we're going to have TMA work in this team, be working on this. And then in two weeks time when the sprint and we'll change it up. So having them aligned can be really useful. For some organizations, it works better not to have them aligned just for logistical reasons. So safe, you've only got one meeting room. Then if you have all of your scrum teams starting aspirin and ending, They're spent on the same day. They're both going to want the meeting room for Sprint Planning and for retrospectives on the same day. So in those cases, you might actually want to stagger of having sprint team a star here and do a two-week sprint and sprint team B start here like a week later. So the offset, so they're not running into these meeting with conflicts. In terms of aligning on aligning the different spent teams. This is where varying the sprint length can be really useful. So say you had TMA and then you just bought team be on a week later. But you actually want to align their sprints and you could have team a do a three-week sprint, so they both end at the same time. Or you could have TB come down to a one-week Sprint. And then after that they go back to if you're using two-week sprints by default, they go back to the two expense and then aligned. So just you can do it whichever way you want, but just having a little bit before about whether you want them aligned or not and how you're going to align them using sprint lengths can be really useful. 63. Other methodologies: This course has focused on Scrum, but there are other agile methodologies you might want to use from time to time and over frameworks that you might want to bring in alongside SCRUM that really compliments grown. So in this module we're going to discuss them over agile methodologies and frameworks that it would be really useful for you to know about when working inside of Scrum. 64. Kanban: Scrum and Kanban are probably the most popular Agile frameworks for managing projects. So when would you use squirm and when would you use Agile was comes really well-suited for delivering new projects where you're building something, a Greenfield thing, you've got a piece of work to do. You know, you've got, say, six months to do it in. And you just need to get through all of the things. Kanban tends to be more suited to or kind of business as usual environment. So maybe you've already built your e-commerce platform. It's live and you just need to see what comes up. Little improvements, little fixes. You don't have the kind of big product roadmap you've gotten grown. But you do need to respond to things much faster because you're dealing with live issues on the website. So kanban works a bit differently in that there isn't sprint scrum. We've got this idea of sprints and we've got, say, a two-week block. We decide what we're gonna do it and start with two weeks and we do it for two weeks and we'll review what we're gonna do. In Kanban. There's continuous board and the product backlog. And the kind of what we think of the Sprint Backlog, the to-do list, all the same thing. So the product backlog is all, all in the to-do column on the board already and in priority order so you pick up the top one. So let's say, let's take our e-commerce platform again. We've got it live. And we've noticed that the currency symbol isn't quite displaying right? For some users. And that's a really big issue because it's around payments. So the product owner would raise a ticket to say, currency symbol not displaying correctly, probably send that straight to the top of the backlog. So the next engineer to pick up something, we'll be able to pick that up. So instead of having these sprints, everything is just in one list. You pick up the top thing and if something needs doing urgently, you just bring it in and put it straight to the top of the the backlog so that you can get working on it. Now, this means that in Scrum, we measure velocity. The how well we're doing is the more points we can get food per sprint, the better we're doing. In Kanban, we talk about cycle time. So from the point that the ticket is raised, how quickly can we get it across the board and out released and done. So as a quick summary, Scrum is great for when you've got fixed pieces of work and you're happy to work in those two-week sprint once you've got something out there and you just need to make little tweaks. And you're less worried about doing a big piece of work. You just need to get those fixes at quickly. Kanban can be more useful. There. 65. Extreme programming: Extreme programming is an agile approach to writing code. Like Agile itself is not a clear set of rules, but there's once bunch principles and a bunch of techniques that form together to form what we would call extreme programming. Often involves multiple people working on the same piece of code. So this could be code written in pairs, Pair Programming, where one person is the pilot actually typing the things, but they're collaborating with someone sat next to them talking through the decisions that both able to spot what's working and how to design it. You can even scale up to mob programming. So having four or five people are looking at one piece of code, either on their own computers, collaborating real-time or all sat round wound computer, if that works for you. It ensures really high-quality code that way. But of course it takes longer. If you're in pairs, then there's only half of your engineers are writing code and mob programming even more. So. Code should be extensively reviewed and approved by someone else. So this should be across everything you write. If you write a piece of code, send a pull request or a code review to someone else. And someone else should look through that code, make sure it makes any sense. Give comments and pass it back to the person. If a passage straight away or if there is any changes needed or suggested, pass it back to the author to see if they want to make those changes. Automated tasks should be written for everything. So moving towards this idea of continuous integration and continuous delivery should be an automated tests for every piece of functionality we write, because it's impossible for human testers to pick all of it up, keeping it as simple as possible. So really, we always want to write as little code as possible and make it reusable. And if we can write one piece of code that we can use in three different places and delete the old bulky code, then that's great because fewer lines of code means fewer places where stuff can go wrong. Then test-driven development, which we're going to talk about in the next lesson. 66. Test-driven development (TDD): Test-driven development, also known as TDD for short, is a way of writing code where we write the unit test before we write the actual code itself. Why do we do this? Well, it prevents us from adding code that we don't need. So we talked earlier about this idea of writing a user story and saying, as a user I want to do this. And then we can write the code knowing that as soon as we meet the acceptance criteria, then we have fulfilled the job. Well, this is basically the same in that we write the test first to say what this code needs to be able to do. And then we write the code to fulfill that text. So as soon as the unit test is passing, we now we can start writing code. We don't need to add any other bloat because we've got that passing unit test and therefore it does everything we need it to do. So writing the test first and then the functional code afterwards helps us ensure that everything has test coverage on it. And two, we're not adding any bloat to the code because we can stop as soon as the test is successful. 67. Behaviour-driven development (BDD): Behavior-driven development is an extension of test-driven development, where we write our tests in user stories and then we write the code to fulfill those user stories. So what does that really mean? Well, let's say we are coding the checkout system for our e-commerce platform. We might write a story like, as a customer, I want to be able to view the total of my basket. Or as a customer, I want to be able to make payment for my order. And that would be the language that we write the test in. That would be our test say, and it's very understandable. Anyone can come look at that, the product owner could write themselves. Anyone looking at the test, even a non-technical person, understand what's going on there. We then have a layer of code in the middle, which translates that into an actual tests over saying, I want to make payment on my order. What are the what are the automated steps to actually test that? So having the Natural Language translated into a test. And then of course we have our functional code, the actual e-commerce platform itself. And so there's kinda 33 pieces in there. What's, what's the benefit of doing this? When we write the code in natural language. Everyone can understand it, the product owner, non-technical stuff and come in and see exactly what we're testing. Second, it really focuses on fulfilling those user requirements. So we can write our test first. I need the user to be able to complete this payment. Then we write our test and our functional code to fulfill that. And as soon as we fulfilled that, we can stop. We're not adding any extra bloat because we know that that user story is defined and we've already got complete test coverage on it. So we know we can run it through a continuous integration pipeline and everything will work great because the test coverages there, there's nothing extra that we need and everyone can understand what's going on. Now, there's a number of popular behavior-driven development BDD frameworks out there. We've got cucumber in Ruby, we've got b hat in PHP, we've got J behave in Java, but whatever language you're working in, there's probably a BDD framework out there. So I'd recommend going up, having a look around and seeing what's there and trying it out and seeing how you get on with it.