 Okay, now that we discussed XP, we continue with another really, really popular method which is called Scrum. And in contrast to extreme programming, Scrum is much more about the management of the software product and it does not prescribe just as many techniques. And that means that you can combine it with a lot of different approaches. So for example, during your development, you can do pair programming, you can do test driven development or you can do something else, but you can tailor it. So there's the big difference and that's also why Scrum is extremely popular because it fits into a lot of different approaches. That means you'll find a lot of companies that do Scrum in very different variants and different versions to the point that it might not really resemble the original idea anymore, but nevertheless, this is the reason why Scrum is so extremely popular. Here you see the figure that describes the Scrum process and I will just walk you through the different steps, the different deliverables and the different people that are involved here. So we start here on the left side with what is called the product backlog. The product backlog is a collection of typically user stories. So there might be user story here and user story here. And as you learned in the requirements lectures, they are typically formulated in the way that you say, as a user, I want to be able to, then you have a functionality and then in order to, and you get the benefits so that you directly know why this is useful and what the customer value is. This product backlog gets populated in the beginning, so you just try to get all sorts of things in there and of course it's flexible. That's indicated by the arrows here. It can change over time and since we are in an agile development, we expect change. So we expect this product backlog to change. What happens then is that we have increments that in our case are called sprints as I've already used in the other videos and each sprint is about two to four weeks in Scrum. And what we do is in the beginning of the sprint, we take items from the product backlog into our sprint backlog. So this is sort of our plan for this single sprint for the two to four weeks and this is what we want to complete within two to four weeks. Then we break those down into smaller chunks so you can imagine you have one user story and you sort of break it down even further. And the idea is that you get small pieces that a single person can work on. These are then chosen by the team members, they're not assigned, they're chosen. And then the actual development starts. So the Scrum team, which is usually seven plus minus two people, so five to nine people, they implement and deliver something at the end, which is our increment. Now they have a couple of practices that are going on. First of all, they have a so-called daily Scrum or daily stand-up meeting. That means in the morning when everyone is starting the work, everyone stands up and one by one, you discuss what you have done the day before, where you are maybe stuck and what your plan is for the current day. And the idea with this meeting is that first of all, you are sharing knowledge. Everyone is up to date with what the others are doing and maybe can help out if they struggle. And the idea with standing up is that the meeting should not go over time. So this should go really quick. And just by standing up, you encourage people to be quick and not endlessly discuss something. So that's the so-called daily Scrum. And then you have the sprint review. That is whatever you've done with the sprint, you have some increment, you have some deliverable and that is being reviewed with the customer. So you essentially demonstrate what you have produced in the sprint and it should be something that gives functionality that can be run. And then that is being reviewed and that usually can lead to new changes in the product backlog. So you might realize that something was wrong before or that you need something else that you didn't realize before. So that's something you do in the sprint review. Once that is done, you have an increment that you could deploy or just continue working on. And then the team goes on and does a so-called retrospective. So they reflect on how did the sprint go. They basically do process improvement. They discuss what went well, what did not go well, what should we be changing in the future. That's what they do here. And once they're done with that, they go into sprint planning for the next round. So they go back to the product backlog. They choose items that are prioritized and work on them in the same way as before. That's overall what Scrum is about. And this just continues forever until the project is done or until the product is being stopped, worked on. But this is in a nutshell what Scrum is. Now we should maybe discuss the different roles here. We have already discussed the Scrum team. The Scrum team, as discussed, is 7 plus minus 2 people. And they are what is called cross-functional. They don't have specific roles. So in this team, you don't have a manager and a tester and a developer. But everyone should be doing everything. They should have the same responsibilities so that things don't get pushed to a specific person. You don't have the testing person. So everyone does the same. They are self-organized. So there's no one that tells them exactly what to do. I was saying that here, the tasks get chosen by the team. It's not like someone assigns. It's as you are doing this, they're chosen themselves. So there's a lot of independence within this team and they have collective ownership of the code. So it's not like if someone writes a function, it's that person's function. But everyone owns the code collectively. Then we have one special role in this team. And that's the role of Scrum Master. The Scrum Master is a facilitator. It is not a manager. So again, the Scrum Master doesn't tell the team what to do. What the Scrum Master does is mainly two things. First of all, he or she serves as someone following up on the process. So the Scrum Master makes sure we're doing the daily Scrum. We're doing a sprint review. We're doing the right practices at the right time and tries to remind the team of what kind of things they should be doing according to Scrum. So basically following up on what the process is about. The other thing the Scrum Master does is communicate with the outside world and more importantly, protect the team from the outside world. So if someone comes and wants to assign the team something or wants them to do something else, it's the Scrum Master's role to say, no, we are working on this user story right now and we're in the middle of the sprint, so the team is not going to do something. So that's basically the Scrum Master process improvement, reminding the team what they should be doing and protecting the team from the outside world. But the Scrum Master is a team member as well. So he or she is also programming, testing, just like the others. And then finally, we have the product owner. The product owner is basically a customer representative. So it is someone who speaks with the customer's voice that knows what is needed or what is wanted at least and that also has the authority here to make decisions, say, this is acceptable, what you just did, maybe we should be adding something to the product. So basically someone that you can constantly ask, not only at the end and the beginning, but also during the sprint that you can get feedback off. So that's the product owner, often called PO, that you can discuss in the sprint review, but also during the sprint you can get regular feedback. And then it's, of course, very important that the product owner has some kind of influence on the product backlog. For example, it's typically the product owner's responsibility to prioritize the user stories in the backlog. So that's the idea of the product owner. And that essentially concludes our scrum process. As I said, it's fairly simple. What you add to this or remove is then essentially up to you. So you can, as I said, in these two to four weeks that you're implementing, you could say we're doing pair programming or we could be doing test-driven development, continuous integration, other practices that we think are useful, but it just gives you the frame of how you work in these iterations. So that's scrum. And now next on in the last video we discuss a bit what industry is actually using. I've already been mentioning that throughout a bit. And then we conclude with some of the issues with agile development. So things that you need to be aware of if you want to develop in an agile way.