 Hello, welcome to the session on agile Scrum methodology in continuation with the previous video. Let us see the learning outcome. At the end of this session, students will be able to apply the Scrum methodology for software development, identify the difference between the water ball model and Scrum methodology. Now pause the video for a while and mention the different Scrum team in a Scrum methodology. In the Scrum framework, all the work delivered to the customer is done by a dedicated Scrum team. A Scrum team is a collection of individuals working together to deliver the requested and committed product increments. Product owner, development team, and Scrum master are the team members. The main source of information about the project is the project backlog, which defines the requirement the application meets in order to be successful. Requirements are expressed as user stories of the format. User stories or just stories are the short statements identifying the type of person. The functionality they need to perform in their own terms and the value they expect to achieve from it. Stories are intentionally expressed in very personal terms and are kept to what would fit on an index card. Keeping the story short is important because it ensures the requirements are fine grained. Next, we will see the requirements how they are collected in different forms. It is often helpful to categorize the stories as sagas, epics, and stories to reflect differences in their scope and lifespan. Sagas are big picture requirements that are extremely broad in their scope. An example of saga might be as a end user, I want to use an application that has exceptional performance and responds to my requests within a matter of seconds so I can quickly complete my work and stay focused on my immediate task. This type of requirement is very broad in its scope and sets an expectation for all functions in the application. The next type of story is an epic. Like a saga, epics have a lifespan of multiple sprints and cannot be considered complete until all stories based on them are also complete. However, epics have a narrower focus than a saga and although still a broad in nature. They can be completed within a few sprints. For example, as a content contributor, I want to categorize the content I create so I can ensure that readers can easily locate it. This type of requirement will result in multiple stories defining how content categorizes or defined and maintained. How they are associated with the content and how search functions utilize them. The user stories is a most granular description of the functionality. Stories describe the deliverables that can be completed in a single sprint. An example is as a experienced end user, I want to save my work using a command key sequence so I can quickly save my work without multiple clicks. It's important to note that there are many details the end user may not be aware of or even care about when it comes to specifying a requirement. It's up to the product owner and development team to refine the stories so they are actionable. In many cases, this means that the sagas, epics and stories provided by the customer must be decomposed into more discrete and therefore actionable units of work. Does the product meet the needs and expectation of the end user? The question is the ultimate major of success for any project. But metrics are also useful to the team in their progress and efficiency. Too simple and effective metrics are the burn down chart and velocity. Both are based on the story points, which is a major of relative effort or difficulty required to complete a given story. We will see in detail about the burn down chart. This chart is used to provide a graphical view of the number of stories in the backlog that have been completed against the total number of remaining across the sprints. This burn down chart is used in the industry to track how much work is remaining for the project or how much task to be completed. The main processes contained in scrum are the sprint, sprint planning, the daily scrum meeting, the sprint review and the sprint retrospective. Sprints are the application development cycle lasting from 1 to 4 weeks. Sprint length is fixed across the life of the project and is chosen by the team. A fixed number of user stories are assigned to each sprint. This is not to say that stories cannot be added to the sprint, just that they cannot be added if doing so exceeds the capacity of the team to create, test and deploy a working application by the end of the sprint. It is quite often the case that teams under the estimate the number of stories that can be completed and have to be added stories to fill out the remainder of the sprint. At the start of each sprint, the product owner defines a goal for the sprint and identifies which stories need to be completed to achieve it. The development team selects stories from this pool, reviews them and commits as a team to their completion. This includes considering both the individual and collective complexity of each story using the story points. One outcome of the review may be that the goal needs to be decomposed across multiple sprints if it exceeds the capacity of the development team. The team also plans for how they will work together to complete the sprint. This may include discussions around the risks and contingencies, test plans. An option available to the development team is to pair the members of the team to work on certain stories. For example, it may be advantages for a front-end developer and the back-end developer to pair with one another to ensure that APIs are well established. During the course of the sprint, the scrim team gathers a daily for 15 minutes of meeting to report the progress and roadblocks. This meeting is referred to as a daily scrum and its purpose is for each member of the team to review what was accomplished towards the sprint goal. Since the last meeting, what is to be accomplished by the next meeting and to identify any obstacles? The goal of this meeting is to make sure that there is a transparency across the team to both success and roadblocks. The daily scrum is not intended to solve issues or problems during the meeting but expose them to the entire team and 40 mates to schedule the time to work on them. At the end of each sprint, a sprint review is conducted to demonstrate the working product to the customer. This is an all-hands meeting attended by the customer representatives, the product owner, and the scrum team. This meeting is an opportunity to get a direct customer feedback on the state of the product, discuss the issues and possible changes or new features and to decide on what to do next. The sprint review allows the development team to receive unfiltered feedback directly from the customer and involves both the customer and the development team in identifying the next steps. In this respect, the sprint review provides timely and relevant input to the next sprint planning session. The sprint retrospective is conducted by and for the scrum team to promote continuous improvement. It is the primary means to the team users to improve their work and to drive value not just for the customer but also for themselves in the form of a more integrated and smoothly operating team. Scrum is an effective methodology that is simple to understand but often challenging to implement due to its radical differences from traditional methodology. Next, we will see a MCQ question to reflect the content what we learned. Product backlog should be ordered on the basis of the answer is the value of the items being delivered. The product backlog that contains the items that to be delivered. Next, one more MCQ. In an agile environment, what is the main responsibility of the tester? What is the role of the tester? The answer is in agile team it is a cross functional team so there is no separate tester as all the team members they know the concept of testing so the answer is E there is no role of as a tester in a scrum these are the references I refer thank you.