Scrum Master Full Course 2026 | Scrum Master Tutorial | Scrum Master Training | Simplilearn

Key Takeaways

Hey everyone, welcome to our scrum full course. Scrum is simple but powerful agile framework that help teams stay organized, work smarter and deliver projects even faster. By breaking work into short sprints, team can quickly adapt, gather feedback and keep improving. As more companies adopt agile, the need for scrum professionals is only going to grow and in 2025 and beyond. So in this course, we will dive into scrum. You'll learn the core principles and understand the key roles like scrum master, product owner, development team. You'll also get handson with tools like product backlog, sprint backlog, plus steps for scrum certifications like TSM. And don't worry, we'll even help you prepare for scrum job interviews. So, let's jump right in. Before we commence this, just a quick information. If you're interested in elevating your career and becoming a certified professional scrum master, then our best retail certified scrum master certification is your ticket to success. We guarantee you will pass on your first attempt as you join our 20 plus live cohorts each month for 16 hours of interactive training led by globally renowned certified scrum trainers. You will engage in hands-on learning through role plays simulation case studies and gain complimentary access to agile and scrum courses. Enjoy a 2-year membership with Scrum Alliance. Earn 20 PDOS, 16 SEOs, and benefit from our 100% money back guarantee program. You will also get to unlock higher salaries and exciting job opportunities. So hurry up and enroll now and find a course link in the description box below and in the pin comments. So guys, what is basically in Scrum? Scrum is an agile framework that has revolutionized the way complex projects are managed and completed. Its adaptability, focus on collaboration, and iterative approach makes it an ideal methodology for dynamic and fast-paced environments. While scrum is most commonly associated with software development, its principles and practices can be applied to various industries to enhance efficiency and product quality. This comprehensive tutorial aims to provide you with a deeper understanding of. So this is the first scrum role that we see in scrum methodology that is a product owner. This individual is basically responsible for defining and prioritizing the product backlog, ensuring that the team focuses on the most valuable task. The product owner works closely with stakeholders to gather requirements, set clear goals, and make informed decisions about the product direction. The key responsibilities of the product owner includes defining the product vision and roadmap, creating and managing the product backlog, prioritizing backlog items based on value, risk and urgency, ensuring that a team understands the backlog items and their importance and also accepting or rejecting completed work based on predefined criteria. Next role we have is scrum master. The scrum master is a facilitator and coach who ensures that scrum framework is followed effectively. This role involves removing obstacles that hinder the team's progress, promoting a culture of continuous improvement and fostering collaboration. The scrum master act as a servant leader supporting a team in achieving their goals without dictating how they should work. The key responsibilities of the scrum master includes facilitating scrum events like sprint planning, daily scrum, sprint review and sprint retrospective. Then comes removing impediments that block the team's progress. Moving ahead, we have also coaching the team on scrum practices and principle. Then we have a thorough discussion on protecting the team from external distractions and interruptions. And finally, promoting a healthy team dynamic and addressing conflicts. Next one we have is the development team. So guys, the development team consists of professionals who work collaborately to deliver a product increment. This self-organizing team is crossunctional, meaning it possesses all the skills necessary to complete the work without relying on external sources. The development team is accountable for creating highquality increments that meet the definition of done. The key responsibilities of development team includes estimating planning work during sprint planning, collaborating daily to achieve the sprint goal, delivering a potentially shippable product increment by the end of the sprint, then continuously improving their processes and practices and finally maintaining transparency through regular communications and updates. Now let us move on and understand about scrum artifacts. The first one that we have all over here is product backlog. The product backlog is a dynamic list of all the works needed for the product. It includes features, enhancements, bug fixes, and technical tasks. The product owner is basically responsible for maintaining and prioritizing the backlog, ensuring that it reflects the current needs and goals of the project. The product backlog is continuously refined with items being added, removed or rep prioritized as necessary. The product backlog serves as a single source of truth for the team providing a clear road map of what needs to be done. It is essential that backlog items are well defined with clear acceptance criteria to guide the development team and delivering the expected value. Then we have the sprint backlog. The sprint backlog is a subset of the product backlog containing items selected for the current sprint. During sprint planning, the team decides which backlog items they can commit to completing within the sprint. The sprint backlog also includes a plan for how the team will accomplish such work. Sprint backlog provides a focused and actionable plan for the team outlining the tasks and goals for the sprint. It is a living document continuously updated as the team progresses and learns about the work. The sprint backlog helps the team stay organized and aligned with the sprint goal. Then we have is increment. Increment is a sum of all the work at the end of the sprint. It represents a potentially shippable product that meets the definition of done, a set of criteria ensuring that work is complete and of high quality. The increment includes not only the new features added during the sprint, but also any improvements or fixes made to the existing features. The increment provides tangible evidence of progress allowing stakeholders to inspect and evaluate the product. It serves as the basis for feedback and decision-m enabling the team to adapt and refine their approach in subsequent sprints. Then we have is sprint. Now let us move on and discuss about some of the scrum events. The first one that we have all over here is sprint. A sprint is a time box period typically lasting 24 weeks during which the team works to create a product agreement. The fixed duration of the sprint provides a regular rhythm for the team promoting consistent delivery and continuous improvement. Each sprint begins with a sprint planning and ends with a sprint review and sprint retrospective. Next one we have is sprint planning. It is a event where the team defines what will be accomplished in the upcoming sprint. The product owner presents the high priority backlog items and the team collaborates to select those they can complete within the sprint. Together they set a clear sprint goal and create a plan for achieving it. During sprint planning, the team breaks down the selected backlog items into smaller tasks and estimates the effort required. This detailed planning ensures that everyone understands the work and how it contributes to the sprint goal. A sprint planning sets the stage for a focused and productive sprint. Next one we have is the daily scrum. Daily scrum is a short time box meeting usually lasting for 15 minutes held every day during the sprint. The purpose of the daily scrum is to synchronize the team activities, discuss progress and identify any obstacles. Each team member shares what they did the previous day, what they plan to do today and any issues they are facing. The daily scrum promotes transparency and accountability ensures that everyone is aligned and aware of the team status. It also provides an opportunity to quickly address and resolve impediments keeping the team on track to achieve the sprint goal. Next we have all over here is called sprint review. So guys sprint review is held at the end of the sprint to inspect the completed work and get the feedback from stakeholders. The team demonstrates the product agreement, highlighting what was accomplished during the sprint. Stakeholders provide input and the product owner updates the product backlog based on the feedback. The sprint review fosters collaboration and transparency, allowing stakeholders to see the product's progress and influence its direction. It also provides an opportunity to celebrate success and identify areas for improvement. And finally, we have the sprint retrospective. The sprint retrospective is the final event of the sprint where the team reflects on their processes and practices. The goal is to identify what went well, what could be improved, and how to enhance their performance in future sprints. The team discusses these insights, creates action items to address any issues. The sprint retrospectives, promotes a culture for continuous improvement, encouraging the team to learn from their experiences, and make incremental changes. By regularly reflecting and adapting the team can optimize their processes and achieve better outcomes. Now let us understand the scrum process flow. The scrum process revolves around the sprint cycle beginning with the sprint planning and ending with the sprint retrospective. The cycle ensures a regular cadence of work and continuous delivery of value. If we talk about the first one, we have the sprint planning. Here the team selects the item for the product backlog and defines the sprint goal. They break down the work into smaller task and create the plan for the sprint. Now guys let us discuss about the scrum process flow. The first one that we have all over here that is called as sprint planning. Here the team selects the items from the product backlog defines the sprint goal. They break down the work into smaller tasks and create a plan for the sprint. Next one we have the daily scrum. Daily scrum. Here the team meets daily to discuss progress plans and challenges. This meeting keeps everyone aligned and allows for quick adjustments. Third is sprint review. At the end of the sprint, the team demonstrates the completed work to the stakeholders and gathers feedback. The product owner updates the product backlog based on their feedback. And fourth one we have all over here is sprint retrospective. Here the team reflects on their processes and practices identifying areas for improvement. They create action items to enhance their performance in future sprints. I hope so you would have got a brief idea regarding scrum process flow. Now let us move on to understanding the benefits of scrum. So guys, scrum offers several significant benefits that can transform how teams work and deliver value. Here are some of the key advantages. The first one that we have all over here is increased transparency. Scrum promotes transparency through its regular events and clear artifacts. A daily scrum, sprint review and retrospective ensures that everyone is aware of the team's progress, challenges and successes. This transparency helps build trust among the team member and stakeholders fostering a collaborative and open working environment. Next one we have all over here is improve team collaboration. The collaborative nature of the scrum encourages team members to work closely together leveraging their diverse skills and expertise. The scrum master facilitates this collaboration helping the team communicate effectively and resolve conflicts. This teamwork leads to better problem solving, innovation and overall productivity. Next one we have enhanced ability to adapt to changes. Scrum's iterative approach allows teams to quickly adapt to changes in requirements, market conditions or customer feedback. By delivering small functional increments regularly, the team can gather a feedback and make necessary adjustments. This flexibility ensures that product remains aligned with the stakeholders needs and expectations. And finally, it provides faster delivery of valuable products increments. Scrum's time box sprints drive the regular delivery of product increments, enabling faster time to market. This rapid delivery cycle allows stakeholders to see tangible progress and realize value sooner. It also reduces the risk of project delays and enhances the team ability to meet deadlines. Now let us discuss some of the common challenges of following scrum methodology. We all know that scrum offers many benefits but it also comes own with its own set of challenges. Here are some of the common issues teams may face. The first one that we have all over here is resistance to change. Introducing scrum can be met with resistance. Especially in organization accustomed to traditional project management methods. To overcome this resistance, it's important to provide education and training on scrum principles and practices. Involving team members and stakeholders in transition progress and highlighting the benefits of the scrum can also help build support. Next, we have handling distributed teams. Distributed teams can face communication and collaboration challenges. To address these issues, it's crucial to leverage technology tools such as video conferencing, instant messaging, and collaborative software. Establishing clear communication protocols and regular virtual meetings can also help maintain alignment and cohesion among team members. Then we have managing large projects with scrum. Scaling scrum for large projects can be complex. One approach is to adopt frameworks like scrums of scrums nexus or safe which is scaled agile framework. It provides guidelines for coordinating multiple scrum teams ensuring that teams are crossunctional and self-organizing with clear communication channels which are very very essential for managing large projects effectively. Now let us dive into most interesting part that is what are the tools and softwares which are used for scrum. So guys several tools and softwares can support scrum practices enhancing productivity and collaboration. Here are some of the most popular options. The first one I would recommend is Jira. Jira is widely used project management tool that offers robust support for scrum. It provides features for creating and managing product backlogs, sprint backlogs, and tracking progress through visual boards. Jira's customizable workflows and reporting capabilities make it a powerful tool for scrum team. Next one we have all over here is Trello. Trello is a flexible, user-friendly tool that uses boards, lists, and cards to organize tasks. It's well suited for scrum teams, allowing them to create and manage backlogs, plan sprints, and track progress. Trello's simplicity and visual nature make it easy to use, especially for smaller teams or project. And finally, we have Azure DevOps. Azure DevOps is a comprehensive suit of development tools that supports scrum and other agile methodologies. It includes features or backlog management, sprint planning, continuous integration and deployment. Azure DevOps integrates seamlessly with other Microsoft tools making it a good choice for teams using Microsoft ecosystem. So guys in this tutorial we have covered the fundamental aspects of scrum including its roles, artifacts, events and processes. So what is safe scrum master certification? Safe scrum master certification is a badge that shows you know your stuff when it comes to scrum lean and agile ways of working. It's like a stamp of approval that says you are great at managing agile projects, especially in big companies. To get this certification, you have got to prove you really understand safe principles and how to use them in real situations. There's an exam you have to pass called the safe SSM exam. It tests what you know about the safe framework and how you would handle different challenges. Now, let's break it down. Scrum is a way of working where teams tackle big projects in small and manageable steps. Lean is all about being efficient and cutting out waste. And agile is a mindset that focuses on being flexible and responding quickly to change. Safe combines all these ideas and adds a layer for working in big organizations. Imagine you're in charge of a project in a big company. You need to make sure everyone on the team knows what you are doing and those things are running smoothly. That's where being a safe scrum master comes in handy. You will know how to use scrum to break down the projects into smaller task. You will also use lean principles to keep things moving quickly and efficiently and you will have that agile mindset to adapt to any changes that comes your way. So getting certified as a safe scrum master is like saying hey I know my stuff when it comes to managing agile projects in big companies. It's a way to show employees that you have got the skills they need to keep their projects on track and their teams working smoothly. So this was about safe scrum master certification. Now let's understand about the exam pattern. So understanding about the exam pattern. The safe scrum master certification exams follows a specific pattern designed to access your understanding. Here's what you need to know about the exam. So the duration is 90 minutes to complete the exam. Then number of questions. So there will be a total 45 questions. And to pass the exam, you will need to score at least 33 out of 45 questions correctly, which amounts to 73%. Now talking about the competency level, the exam is geared towards individuals at an intermediate competency level. This means you should be proficient and capable of performing task with some assistance. Now the question format questions for the exam will be either multiple choice question where you have to choose one answer or multiple select format where you can choose two or three answers. Now talking about the delivery the exam is conducted online via web- based platform. It's a closed book exam meaning you can't refer to any materials during the test. You'll also not allowed any outside assistance and remember it's timed so manage your time wisely. Now coming to the main part that is the cost of the exam. So the course of the first attempt is included in the course registration fee if you take the exam within 30 days of completing the course. And however, if you need to retake the exam or if you attempt it after the 30-day window, there's a fee for $50 per attempt. So it's like that. All right. So this was about the exam pattern. Now coming to the career opportunities after certification. So after completing the safe certified scrum master certification you can target a variety of job positions that leverage your knowledge of agile and scrum practices. Some of them are scrum master, agile coach, product owner, project manager, program manager and iteration manager. So these are the some of the positions you can opt after doing this certification. All right. Now let's understand how to become a safe certified scrum master. So let's divide the procedure or plan into three steps. Step one is create a proper study plan. So let's understand that first. So preparing for the safe certified scrum master exam starts with creating a study plan. This plan outlines what you need to focus on. First identify the main goals and the important ideas for the exam. Understand the key concepts thoroughly. This helps you prioritize your study time and ensures you cover all the necessary topics to succeed in the exam. So this was about the study plan. Now coming to the next step which is prepare for safe certified scrum master exam. So basically the training part for preparation purposes consider enrolling in a safe scrum master certification course over 16 hours of live instructorled sessions. You will delve into the intrasties of scaled agile framework mastering agile development at a scale itteration planning and fostering high performing teams with a one-year membership to the safe community platform. Access invaluable resources to support your journey. Professionals who pass the safe scrum master certification exam from simply learn will receive safe scrum master certificate, safe scrum master digital badge for online profiles and much more. You will get the link to the safe scrum master certification course by simply learn in the comment section below. All right, now let's talk about the study material thing. So supplement your learning with official course materials including the safe certified scrum master guide and additional resources provided by your chosen training provider. As I've mentioned, you can go through the safe scrum master certification by simply learn and you'll get all the resources in that particular training course. All right. Now coming to the next thing that is the third step which is mock test. So mock test taking mock test is an important part of preparing for the safe certified scrum master exam. These practice test mimic the real exam helping you get familiar with the format and types of questions. By giving mock tests, you can assess your readiness and identify areas where you need more practice. It's a great way to build confidence and improve your chances of success on the actual exam. After that, you can go for test analysis. Analyzing mock test is crucial for safe surface scrum master exam preparation. After taking a mock test, review your answer to understand where you went right and where you made the mistakes. Identifying the patterns in your errors and focus on improving those areas. This should be your goal. So this analysis helps you fine-tune your study plan and strengthens your weak points increasing your chances of performing well on the actual exam. And the last step would be to go for the exam. So by following these steps and maintaining consistency in your preparation, you can confidently pursue your goal to become a certified safe scrum master. With a solid study plan, regular mock test and through analysis, you will be equipped to ace the exam and excel in your agile career journey. Why do we need scrum meeting? Alignment ensures everyone is on the same page regarding project goals and progress. Transparency promotes transparency by sharing individual accomplishments, plans, and obstacles. Collaboration fosters collaboration among team members by identifying dependencies and opportunities for assistance. Adaptation allows teams to adapt and adjust their plans based on daily progress and emerging challenges. Efficiency helps in identifying and addressing issues early, preventing delays and ensuring smooth project flow. Moving forward, let's dive into advantages of scrum meeting. Improved communication. Enhances communication among team members by providing a dedicated forum for updates and discussions. Enhanced collaboration. Promotes collaboration and knowledge sharing among team members leading to better problem solving and decision making. Increase productivity. enables teams to stay focused and accountable for daily tasks leading to improved productivity and progress. Quick issue resolution facilitates early identification and resolution of obstacles preventing them from becoming significant impediments to progress. Iterative improvement supports iterative improvement by providing regular opportunities for reflection and adaptation. Next, let's see standard questions of scrum meeting. Question one, what did you do yesterday? Question two, what will you do today? Question three, are there any obstacles or impediments in your way moving forward? Let's see. Facilitation and execution in scrum. Scrum master's role facilitates the meeting, ensuring it stays focused and on track. Time boxing keeps the meeting short and concise, typically around 15 minutes or less. Adapting format allows teams to modify the format or questions to better suit their needs and context. Staying standing encourages participants to stand during the meeting to maintain focus and keep it brief. Let's conclude this video. Conclusion value proposition. The daily scrum meeting is a valuable tool for agile teams promoting alignment, transparency, collaboration, and continuous improvement. Integration with agile principles. It aligns closely with agile principles of frequent communication, adaptation, and collaboration, making it an essential practice within agile methodologies like scrum. By incorporating these, teams can gain a comprehensive understanding of the purpose, benefits, execution, and continuous improvement aspects of the daily scrum meeting within the agile development framework. The demand for scrum certified product owners is surging across multiple sectors signaling robust career opportunities for those with advanced skills. With an expected job growth rate of 25%, product owner leadership roles are listed among the top 10 most promising jobs on LinkedIn and the top six emerging jobs in product development by the World Economic Forum. Average salary for experienced product owners is roughly $1 million and is expected to increase by 10% yearonear. This expanding need spans diverse industries from IT, telecom and government to oil, gas, entertainment, finance and healthcare. Hi, my name is Vijay Bandaru and I want to welcome you to Simply Learn certified scrum product owner certification training. I'm a certified scrum trainer, team coach and enterprise coach from scrum aliens. If you want to elevate your scrum mastery, you are in the right place. As a certified trainer, I'm here to lead you into the depths of agile product management with proven strategies to succeed in any sector. Join us for 16 hours of live instructorled sessions where learning comes alive through games, role plays, simulations, and case studies. Our globally recognized certified scrum trainers, experts in their fields, deliver these interactive sessions. By the end of this course, you will earn 16 SUS plus 16 PDUs with complimentary access to 15 value addition courses worth of $500. You will also get a 2 years complimentary membership of scrum aliens to further your professional development. This course offers a comprehensive journey into advanced product ownership surpassing fundamental concepts. You will explore strategic product visioning and master stakeholder engagement while delving into a real world challenges to hone your agile leadership abilities effectively with a focus on mastering strategic product backlog management and scalable agile practices. You will gain the tools to drive successful product deliveries by enhancing your leadership and collaboration skills. You will have a profound impact on your organization's agility and success. Why take CSPO certification at this stage of your career? The evolving job market landscape demands highly skilled scrum product owners capable of managing dynamic product development cycles. This course prepares you to thrive in roles essential to business agility and innovation. Simply learn is the world's number one online boot camp for digital economy skills training. A global leader in agile training and part of the global registered education aliens. Our experience in CSTs have enabled more than 35,000 learners across the globe to achieve their goals. Ready to improve your product owner skills? Enroll in our certified scrum product owner course and join the global community of scrum professionals who are making a significant impact. Step into the future of product management. Join us at simply learn and transform your professional trajectory with our certified scrum product owner training. Let's reshape the way products are envisioned and delivered. Then there is something called scrum board which is used during this flow of scrum right from product backlog to the creation of that increment. So let us look at what is a scrum board which is used during the scrum practice. So scrum board is a physical or virtual tool that helps team to visualize items in the sprint backlog. So it helps in tracking what is being delivered, what is in progress and what needs to be delivered further. So it shows all action items during the daily scrum helping keeping the team focused on tasks that need to be completion and the priorities of those. The scrum board is usually present in a place that's accessible to all team members. It is a visual board, right? And can be physical whiteboard and stickers or virtual software tools which can be used and displayed on the screen. So the scrum board is divided into different slots like to-do, in progress and done. So when new sprints are started, the existing board is reset and new scrum board is created. So since it is visual system, I think it is taking the thought from Khan. So visual system always works effective because the moment I know I see something is uh put against my name that I need to complete this. It's quite obvious to me that I will put efforts to complete it. So it's a conscious effort what I will put it works on my consciousness. So something which is not visible to me it is that out of sight is out of mind. So I will not work on it. So I may there is a tendency to forget. First slide here has to do with user stories and ethics. And what I want to do team is I want to before we get into the user stories I want to go to the whiteboard and I want to just give you a little bit more information that might help us in organizing our discussion that we're about to embark on here. So a word that is not in our slides is themes. Themes are epics and user stories grouped together. You know, similar epics and user stories grouped together for planning purposes. So an epic is big. Um you would never do an epic in or pardon me, a theme in a sprint. It's too big. Um so it's used for planning purposes. Below that I would put epics. Epics are low priority large user stories meaning that an epic will eventually have to be disagregated into multiple user stories. The reason it would be low priority is because if it w if an epic was higher up on the product backlog, um it would have to be more detailed. That's when you would break it down. So epics are usually going to live at the lower uh priority levels of a product backlog. And as user stories are completed and the epic rises in priority, it will eventually be broken down into um more manageable user stories. So great big low priority user stories. Then we have user stories themselves. User stories are functions or features that the product owner wants to have developed. A user story turns into working software that provides value to the customer. And um and the product owner is the customer voice. product. The owner is the one who would accept or reject completed user stories. And then there are tasks. And a reminder when we were talking about the sprint planning meeting, we said the sprint planning meeting is uh got two parts to it. The first part is selecting all of the user stories that are going to be included in the sprint and then disagregating each of those user stories into tasks. That's done in the sprint planning meeting and then those tasks are the things that are actually then done when the uh work of the sprint begins. User stories can be estimated in story points or ideal days. Most teams favor story points. They might start with ideal days, but they will then usually end up going to story points. Um tasks are uh estimated in I ideal time which is usually hours. Okay, so now back to our slides. So at the top left, a use case could be an example of a user story. So it's something that um the user wants to do and how the system should support it. Um like um a use case could be um select and pay for items in a catalog. Now that could actually be an epic or maybe a theme because maybe it would get disagregated into log on screen uh catalog uh shopping cart and checkout. But the so the use case could either be a standalone user story or it could actually be uh a number of user stories um that would result from it below that requirement. It could be a functional requirement, a technical task, or even a bug fix. So, I'm going to go back to the whiteboard. And a product backlog is going to have a lot of user stories that come from the customer, right? Whatever the customer wants done. But the team may know that it has to do some development work in order for the user stories to even be able to work. you know, there's some system level non-functional requirements that need to be done. And so there could be tech user stories and then can you see this low? I can't see your chats. But then there could also be defect user stories. There could even be risk user stories. Now what could happen is that um the product owner ranks these in priority. So this one first, then that one, then that one. And the team says, well, the only thing is is that um we have to do some development work before we can actually do user story 2. And so what we really need to do is insert that before the uh the second priority user story. And so the priority of the user stories in the product backlog while it might start with just being you know simple functional user stories coming from the uh product owner. It will evolve until it includes some other things that are also considerations when it comes to uh priorities because of you know successor predecessor relationships, dependencies and things like that are um considerations. A user story be uh back to the the uh screen um bottom left now. The user story um can use a fictitious user or a persona to help uh the team or the the team and the product owner to get an idea of okay who's going to be doing this function uh what are they going to need in order to be able to complete the function etc. So you try and um come up with an actual well a fictitious but a person who's actually doing it to kind of get out of the realm of you know listing requirements and you know specs and things like that and say okay what's the user experience need to look like? Top right template a portion of a user story is um let me back up. So, a user story card um is usually going to contain um a brief description of the user story using some kind of a metal language format like we're suggesting right here. as a user or persona, I want this feature so that I can. So, not unlike our um estimating session here as a frequent traveler, I want to eat grapes so I can be healthier. in the one that we uh didn't do uh the inventory system as a customer. Okay, there's a a user. I want to get cash back so I don't have to wait in line at the bank. Okay, here's another user story. As a consumer, I want the shopping cart functionality to easily purchase items online. And maybe that could be customer as well. Um, as an executive, right, as a suit, I want to generate a sales report so I know which departments need to improve their productivity. As a buyer, so you can see I I tried to come up with these different roles right here. Executive, buyer, sales rep, etc. Um, and that's the format. As a type of user, I want some kind of goal um or feature. And uh so that's some kind of a reason um the below that connect connect the dots by writing all of the user stories necessary to uncover the entire use case. So like we were talking about right here, if you want to be able to purchase items online from a catalog, that might be uh multiple user stories in order to support that use case. And so of course um we would want to be able to connect the dots and see where all the user stories fit in into the overall goal of the project or release. And the stories um excuse me um are grouped to form an epic or higher level story. So epic or theme. Um stories can then be split into child stories or task. And so that's what we were covering before, right? So you have um themes up at the top. That's the biggest grouping if you will used primarily for um you know uh high level planning purposes. So, you have your themes, then you have your epics, which are large user stories, um, low priority, and they're going to have to be broken down into smaller user stories. Like in the question that we had at the end of the the last section where um the product owner needed something done and the team said, well, based on the size of this user story, it's going to take three sprints to do. Well, a user story has to be small enough to be completed within a single sprint. So, a sprint can contain more than one user story, but a user story cannot span sprints. So, that feature or function that was in the question was probably more like an epic. was something that would need to be uh disagregated into smaller user stories or perhaps it was more of a use case that would need more than one user story in order to actually deliver the overall use case. Let's see. As a product supervisor, I want to see an unfinished part list at the end of the day so that I can reallocate work the next day. Great user story description. Well done, Vrage. Um, did you hear that team? As a product supervisor, I want to see an unfinished part list at the end of day so I can reallocate work the next day. That is a well-crafted description of a user story. Now, here are some things that I want you to memorize. You were hoping I was done with the memorization part. So, I want you to um remember that we have to invest in our user stories. And I was going over to the whiteboard and I didn't change cameras. So, let me do that. I recommend um you know figuring out how you memorize best so that you can if um well, not if you wanted to. What I recommend is being able to write out all of this stuff on plain white scrap paper in about 14 minutes because that's the amount of free time you have in the tutorial when you're at the uh or when you're taking the test. Um exin does a little bit different. You maybe won't have a tutorial. The only time you'd have a tutorial is if you were at a center taking a test. Um EXIN has other options like you can do a paperbased test. um uh where you get a third party, you know, a buddy or somebody who will agree to sort of proctor the test for you or you can do it on your laptop all by yourself and they have software that watches you while you're taking the test and they require you to take the laptop and do like a 360 so that um they can verify that you don't have any cheat sheets up on the wall or anything like that. But the point is is um you got to have this memorized. um whether you're going to dump it out onto paper or not. Um when I took the test, um I actually did the paperbased option. Um and that was because of some kind time constraints and it was the quickest way to get me into the test. And so I didn't write out any of the stuff I'd memorized, but I had it memorized and I had it memorized well enough that I could kind of recall it in my mind's eye. Okay, so we're talking about user stories and you have to invest in your user stories. You know, I like memorizing things by creating these charts that have the first letter of the word or phrase that you're memorizing in a separate column. And then I make up a story, you know, that uh um reminds me that I've got to have invest. This one is pretty easy. probably just invest works. Um but so let's go over that. I stands for independent. Independent meaning that each user story stands on its own. Um you don't have when we're doing scrum, you don't do a user story that won't result in working software. We just talked about the description of user stories, right? So, it's a user that needs some kind of functionality for some kind of a reason and they're all independent. Will they work together? Of course, they'll work together if that's a necessity. But, um, if you developed a loon screen, you could demonstrate working software for the login screen. There might be another user story that is um you know has to do with displaying uh the catalog and being able to flag or select items that you want to purchase. But there'd be working software for that. Would they work together? Yes. But each user story would complete um or result in some kind of working software and they have to be independent. Negotiable. negotiable in the way the user story is going to be implemented. The product owner doesn't dictate to the team. The team doesn't say it it's only this way and we don't want to hear anything from you. So there are discussions about the size and implementation for each user user story. So the product owner can't make it so detailed that there's no room for discussion and the possibility of you know the team coming up with solutions other than what the product owner was attempting to dictate. Um V stands for valuable meaning each user story has to create value for the customer or the end user. E, it has to be estimable as in estimable. Except estimatable is not really a word. It's estimable. Um, and S is for small has to be small enough to be done in a single sprint. If we're doing two week sprints, has to be able to be done in two weeks or less. If we're doing four-week sprints, it could be a larger user story, but it would still uh have to be done in four weeks or less. And then the last one, the T is testable. Every user story needs to be testable and it needs to be testable at two levels. Remember our triangle needs to be testable at the intrinsic quality level, unit tests, etc. And also testable at the exttrinsic level, which is the customer point of view, which is acceptance. So every user story uh has to be testable. Okay. So that's invest. And so let's add that to our list of things to memorize. Invest. And then the next one we have here is um the three C's of a user story. So the first C team is card. So, user stories should be able to be written on a 4x6 inch index card or some uh media similar to that card. The the second C is conversation. The user story card is the item that is used for the team and the product owner to talk and discuss in order to make sure that the product owner and the team are on the same page when it comes to what is actually supposed to be developed and um uh what you know so what it's supposed to look like at at the end which leads us to the third one which is confirmation. Each user story essentially has to have acceptance tests um in it itself. So card 4x6 conversation that's the starting point that's where uh the team and the product owner discuss and then eventually there will be acceptance tests included on the user story card um in order to be used during the sprint review to um assure that it's acceptable that there's confirmation. Okay. So oh let's add that to the memorization list. So, three C's. All right. Now, I've got an example here of a user story card. So, we're looking right here. And if you were to go out on the internet and search um user story cards, um they would be similar. There would be some differences, of course. Um, but typically what you're going to have is you're going to have a title or a name for the user story and then there's going to be some kind of unique identifier like user story 321. Then there will be the description like we just talked about. As a librarian, I want to have the facility of searching a book by different criteria so that I will save time while serving a customer. Then there might be some other descriptive words or links to other information that might be necessary. And then there would be acceptance criteria or tests. Sometimes these get included on the back of the card, but the point is is that they are on the cord on the card rather. Then there will be an estimate of size. It could be ideal days or story points. As I mentioned, most teams do story points. That's more likely what you'll be tested on as opposed to um ideal days, but you know, we'll cover both so you understand uh the differences. Um there is probably, it's not listed here, but there's probably going to be a um value point assignment. This is where the product owner um kind of determines in a relative way the uh value of the stories just like we were doing in planning poker. The product owner might say well this story is twice as valuable as as uh this other one comparing them together and this is what um these value points are what's used to uh prioritize the user stories. That's supposed to be a V as in value points. And then typically there's also going to be a indication. Sometimes it's just by colors. Um it could be words uh that has to do with um you know where the story came from. Did it come from the customer? That would be considered a functional requirement. Um, if it came from the team, that would be from the technical domain. I'm trying to write where from uh you know, it's not me team, it's the mouse clearly. It's hard to uh do that. That's from where from. Um, here it's got uh customer tech. You could also have defect. You could maybe have risk. Um, and then there's also going to be an X factor, um, which would be some kind of word probably like, um, stable, um, erratic, um, incomplete, something like that to, uh, so that the team is designating the user story in, uh, respect to the amount of uncertainty or risk that's associated with that user story and because all of that's a part of the story, right? The story is going to be turned into working software, there may need to be uh some efforts to actually figure out how to actually do that user story. So that's the X factor. Um over to the right here on the same chart we have some comments about um if you are using a uh software package excuse me like Trello or Jira or something like that excuse me the user story cards will generally be able to contain more information using you know dynamic links and things like that. um could even include things like responsible team member or depending on how you're doing it, you would break the user story down into tasks and you might have team members assigned to various tasks for the user story. Um, okay. So, that's typically what a user story card is like. Sometimes they're cards, sometimes they're like on sticky notes and they're put up on a canban board if you're using canban to track the project. If you have a story that is too large to be completed in a sprint, it's going to have to be subdivided or we call it disagregation into um smaller user stories. And there's uh three ways that we're proposing here that you could go about doing that. You could split it based on operational boundaries. For example, as an operator, one needs to manage reservations, which could be split. For example, there could be one portion that is uh that has to do with making a reservation, another one that has to do with modifying it, and yet another one that has to do with cancelling it. So, um that could be split into in this construct here, three separate user stories. You could also separate based on exceptions or crosscutting concerns. For example, in the beginning, develop only one main path like accept repayment for a loan. Then address exceptions like what if a person um overpays? Then um come up with a user story that recognizes that and processes a refund and or gives the option of allocating the overpayment to a future payment or something like that. and then also um um adds on other concerns like the check access restrictions or record name of operator. So maybe um you know when you're working on uh accepting payments or processing refunds, it's going to check on um who the operator is or track that so that if at a later time, you know, who was it that gave this uh refund here? Well, you could look and see, you know, okay, the the operator's name was recorded or maybe you put some restrictions so that maybe not everybody um is allowed to do a refund and so you would have levels of users that have different privileges. Okay. And then down at the bottom, split based on data boundaries. For an example, you know, as an accountant, one needs to enter balance sheet information. um which could then be split into summary information and separately um uh receivable details or you know maybe you could have AP you know so you could have different portions of the overall um balance sheet um activities that need to be done so enter AR enter AP etc make sense so just kind of uh prompt you, give you some ideas about what to do um in a scrum project if you have the scenario arise where a user stories being estimated by the team and it won't fit into a sprint, it's too big. Now, when it comes to determining value for user stories, this is primarily owned by the uh product owner, right? And it always comes back to money. But money, you know, the value can be looked at from different points of view. So new revenue obviously, you know, getting new customers and having them buy stuff. Um well, below that there's another consideration, incremental revenue. Uh so somebody's in the process of placing an order. Um, maybe there are some premium features that could be add-ons at that point in time. Um, or maybe added later on. So, you have an existing customer who actually buys um more of or enhanced parts of the existing thing they already purchased or are in the process of purchasing. Retained value. So this is um you know retaining customers so that they don't go to a competitor and then the bottom one is operational efficiency. You know how could things be done to speed up the process of whatever it is um so that the cost of delivering uh the product is reduced. So this then leads us to a discussion about priorities recognizing that there are some priority concerns that come from both the customer domain as well as the technical domain and there are some prioritization models. Um if we look right here there is valuebased prioritization and the hierarchy of that would be high value followed by high risk followed by high value and then low risk followed by low value and then low risk. So, you know, we might have written this a little bit differently, but that's valuebased prioritization. And this is primarily the product owner with maybe some input from the team just simply deciding um what he or she wants done most, listening to the team say, well, you know, there's some, you know, greater risks with this user story than that. And so you'd probably want to uh persuade the product owner to take care of high-risk stuff first um because that would have an a uh oh excuse me sorry an impact on the future things that need to be done. There's the can the cano model uh which looks at each of the user stories and classifies them as being mandatory linear or exciters and the mandatory items are those user stories that are musts and they'll never move beyond move the customer or the end user beyond neutral. It's if they're not there it creates dissatisfaction. If the the you the product owner and the team has done a good job in identifying what are the mandatory or threshold items um you would see that um um it just gets it to neutral. That's what's expected for the product. linear items. Um, user stories are those user stories that as they are implemented progressively throughout the project and added to the feature set, it will linear increase customer satisfaction and it can be, you know, in their absence dissatisfaction all the way up to high implementation creating a great deal of satisfaction for the customer. And then the third category is exciters and delighters. Um and those are features or functions. Those are user stories that are not mandatory and the absence of them will never result in satisfaction going below neutral. But by adding them um you could create excitement and delight for the customer. These would typically be things that are features that would be included in a premium version of the product or maybe add-ons that are promoted, you know, at the point of sale. You know, have you thought about this because it'll really help you or whatever. So, that's the Cano model. And then there's Weaguer's relative waiting method. And um this is all using numbers. So each feature is given a value for its benefit and its penalty given a value for penalty meaning what's the pain if that feature or function is not included and then there is um um the cost side and the risk side and then those are all calculated together and that results in excuse me, a ranking or a hierarchy which gives you the uh priority for the uh user stories. Um we also talked about Moscow, didn't we? Did we talk about Moscow? Uh Moscow is another prioritization model. Must, could I said that differently? Must, should could, won't. Moscow. MCW. Must, should could, won't. and we talked about that one. Thank you for that confirmation. Does it seem like a long time ago or is it just me? I know it was just last weekend, but it's like last year. Okay, so now let's talk about velocity. Um, uh, Priyanka, that is exactly right. Um so velocity is the capacity of the team to complete work in a single iteration. So the team has estimated the user stories uh for size or ideal days and um the sprints are going to be three weeks in duration. Obviously not all user stories can be completed in a single sprint and be done with the project. Well I guess maybe I shouldn't say obviously when I'm saying that. I'm thinking well maybe you had a very small short duration project so you could but the point is is that uh it's the team's capacity to um complete work in a given sprint and it is an observation. It's not a prediction. So, if we're working on sprint five and we're working on determining what our velocity is, then um it would be the average of the previous four sprints. If there were any uh outliers, you you would uh disregard those. Um and so it's an observation. If we look over to question or uh box number two here, velocity is used to deal with um determining how many user stories we are going to include in a given sprint and also how many sprints are we going to need to create a release or a set of user stories. And here's an example. In box number three, a team completed five user stories that were sized 5, 3, 8, 13, and two. Two user stories each sized five were left half complete. What is the velocity of the team? And the answer is either going to be 31 or 36. 31 is the sum of the completed user stories. Um, if you were 36, you were claiming half of the two that were five. Uh, so that would be a total of 10. So you claim half of it, which would be five, would take you to 36. But it's not going to be 36 because the only thing that counts towards progress is working software. So even if the team had finished nine out of 10 story points for a user story, meaning it's almost done and then the sprint ends, that doesn't get counted towards velocity. And you don't mess around with velocity. Um, you can mess around with your estimating and you can mess around with um, you know, what user stories are going to be completed in a sprint, but you don't the the velocity is not variable. It is what it is based on past performance. When it comes to levels of planning, we have what's called the planning onion. And let me walk you through this here. Up at the the broadest area is the vision level. So the vision level, that's the suits, right? They're the ones that have the strategy and objectives for the company and where it's going. And so they have that overall big vision for the uh company which is likely going to include products and each product should have a road map. My example of that website that I'm uh working on has uh three versions um which make up the product roadmap. Version one is the free site, version two is the membership site and version three is the um uh the pay referral commissions uh uh version of the site. And the product road map is then supported by releases. So for my project, I have three releases. So all of the user stories needed for the free version are in release one. All of the additional user stories that are needed for the um uh paid version, the subscriber version. Uh and then also for version three. Those are all releases, three releases. And then for each sprint, we will be pulling user stories from the release that we're working on. A release is likely going to take multiple sprints and um and then the sprints are populated by the individual user stories which are then disagregated into tasks and we do the excuse me the daily scrum which is the daily level of planning and coordination. So we call that the planning onion. We already kind of talked about the release and roadmap um concept here. So let's just review this quickly. Um priatorize highle epics and determine goals and releases. So we'll use ethics and themes in order to group things together. You know what should be included in what's released. So what are the goals for the releases? Then the first bullet point establish goals of release based on market demand, regulatory needs or customer expectations. For each release, you want to estimate the target stories. Repeat until the target stories are assigned an iteration length. I should that's it's blending some things here. Um be able to estimate velocity and then uh assign stories to the sprints. So we keep estimating the user stories and we keep organizing uh that until we can do that. we can come up with an iteration length, a sprint length, and then figure out what our velocity for each sprint is and then uh assign stories to the uh the sprints. Uh the the next bullet down, iterate until the user stories and release date meets conditions of satisfaction. So that's uh definition of done or acceptance for the release. And try not to pack too much into a release backlog. So um just like you would not want to pack too many user stories into a sprint, you want to have the timelines appropriate and uh what are included in the uh events uh make sense. Okay, so here's a little bit more about release planning on this slide here. Um, you've got the product backlog here on the left and then we might come up with a release plan which could be flipped and could be looked at uh horizontally. And you probably plan um about three releases in advance um or at least you're doing more of the detailed planning on that. uh because things are going to emerge when we do, you know, sprint one that's going to help in sprint two and things that happen in sprints one and two that are going to help um release three. And then you've got um you know, your subsequent releases where we're just doing very high level planning. It's called rolling wave planning where we do detailed planning for things in the future in tandem with doing high level planning for things in uh the future. Did I say that right? detail planning for things in the near term in tandem with high level planning for things in the future. Um, and we talked about deciding as late as possible I believe meaning that it's better to actually plan the later uh releases uh for purposes of uh making sure we have more information uh the most information available. Okay. So estimation Let's start at the top left. The principles behind estimation. Understand the cone of uncertainty, which is an estimate or best guess to begin with and then progressively becomes more accurate. In fact, let's just take a break and look at the cone of uncertainty. So, at the very beginning of a project, there's going to be a high level of uncertainty. Um, if I were to draw this chart, I would make it a little bit more like this. So, clearly, you're going to derisk the project as early as you can and then eventually all risk disappears when the project is done. Risk is uncertainty. Okay. below that the only estimate that matters is the one given by the team supported by this uh comment here. Nothing is impossible for the one who doesn't have to do it. So the product owner is like team come on you can do this. The team's like no we know what our velocity is. No. The product owner says I'm telling you there's no way that that can't be done. I know you can do it. I trust you. I believe in you. But the product owner doesn't have to do have to do the work. Okay. Top right. Overestimation and underestimation is always going to be an issue that we deal with. It's more likely that we will underestimate than overestimate. And by looking at our velocity from iteration or sprint to sprint, um there could be some information that is um showing us that we're underestimating. For example, meaning um we're thinking we you know the user stories are smaller than they are and that we can get, you know, a certain number done in a sprint and then there's a fail. Well, that would mean then that would be discussed during the retrospective and then we would do something different going forward which might include doing some reestimating. Scrum estimating is not necessarily more difficult. However, scrum exposes bad estimates sooner, which is a good thing. when we were doing our um uh planning poker, you could see that um the first time as a team, you know, we didn't know each other. We didn't know everybody's thoughts and concerns and those kinds of things, you know, get shared and absorbed as a project goes on and so there's a higher awareness of that. So um what we would say is that um using estimation techniques, scrum estimation techniques might be um more inaccurate at the beginning of a project, but they will quickly become very accurate as the um project advances forward. Let's see, is there a question here? Can velocity be increased over a period of time for the project? Yes, it can. Now, it's not that it can't it will increase if the team is learning how to work together better and better. You would expect that if I can just use my mouse here, if we were tracking velocity, so this would be um points completed over here. Uh, let me just do PTS for points. And down here is time. And we go from sprint to sprint, right? You would expect that maybe, you know, the first couple of sprints the team would be learning how to work together and there would be a steep curve and then it would kind of flatten out and maybe have, you know, a slow rise going forward. As the team emerges as a high performing team, they get better at their cross uh functional behavior. You know, somebody's sick, the team just keeps chugging along. um other things, you know, just um Oh, sorry. There I had bumped a thing on my screen there. Um um so the team, you know, learns how to work better together and, you know, their estimates become more accurate, etc. And you would expect a high per a high performing team to have a uh a result like this for velocity where there's quick improvement and then it kind of stabilizes and then begins to tick upwards. Okay, we talked about the cone of uncertainty. Let's talk about ideal time. Um, when we do estimating for user stories, um, we do it in ideal days. When we do estimating for tasks, we do it in ideal time, which means hours. I think that's on the whiteboard or it was on the whiteboard. Oh, it was on it. Um, so ideal time is the amount of time it takes to complete a piece of work. But that's based on the notion that the team member or members are available to do just the work with no distractions or anything at all. So assuming that um Priyanka could sit down at a keyboard and code for eight hours without taking a break for lunch, no phone calls, no discussions, no meetings of any kind, just work eight hours. How much could be done in that eight hours by Priyanka? That's what ideal time is. But the thing of it is is that there is no such thing as somebody being able to spend every minute of every day only doing work. There will be um distractions. So it has to be converted into elaps time. Now we don't convert it to elapse time at the user story level but we do convert it to elapse time when we are dealing at the task level. And what that looks like is, you know, for each team member, you're going to have to do it separately because some team members have more distractions than others. Some might have other duties that pull them away. Um, whatever the case may be, um, you determine how much time in a given day a team member is available to do work. So say it's 5 hours out of eight for one, maybe it's 6 hours out of eight for another, maybe it's four out of eight, but you figure out what it is and then you take the average and that average availability is used then to convert ideal time into elapse time. Uh I should have circled this box here because we talked about this as well. Um and then I already mentioned this here only considers actual work time not the distractions. So that's the concept of ideal time. When it comes to story points it's different than that. They are a measure of size relative to each other. So we were doing planning poker this morning where um we were looking at grapes versus apples and then we were looking at oranges and and what else do we have? watermelons and coconuts and we weren't trying to figure out how much time it would take to eat grapes as opposed to how much time it would uh take to eat a coconut. It's clear that it's going to take longer to eat a coconut because there's more effort involved. So, we have a sense that it's going to take more time, but comparing the coconut to our baseline of two, right? We came up with a baseline of two for the smallest user story. We compare eating coconuts to that baseline and we say, "Okay, you know what? It's going to take more effort to uh eat the coconut than it is to eat grapes or apples. Um, so you can do it like we did. You can also triangulate. Um, for example, when we did our planning project this morning or this morning for me rather at the beginning, um, oh that's not it. That is the daily standup. Here it is. If I had said, team, I want you to pick a small user story, a medium user story, and a large user story. Um, and then we would then compare other stories to those three. And so we would kind of triangulate on it. Um, let's say that we did, uh, you know, two was small. Uh, I'm sorry, I'm saying that wrong. grapes was small, apples were medium, and coconuts were large. Well, if we then looked at orange and we said, well, you know, orange is um smaller than apples but bigger than grapes. So, we would know this would fit in between grapes and apples. Um, and so let's say, you know, we had apples at five and grapes at two, then we would say an orange is probably going to be three. And the values, you know, now I used um in our example the modified Fibonacci series. uh what we do in Scrum and Agile, if we're using story points, we're going to use um a nonlinear scale for the values. So down at the bottom here, there's the modified Fibonacci sequence. The way the Fibonacci sequence works, by the way, um um it's the the value is the sum of the two on the right. So let me break this right here because this is a modified Fibonacci. So 13 is 5 + 8. 8 is 3 + 5. 5 is 2 + 3 and 3 is 1 + 2. If we were doing the real Fibonacci series, this wouldn't be 20. It would be 13 + 8, which would be 21. Um, and I don't know why some use modified Fibonacci and others not. But that's just kind of a common thing to do. If you're doing planning poker, you give everybody seven cards. 1 2 3 5 8 13 and 20. Um, another nonlinear scale is doubling. 1 2 4 8 16. Um, you typically don't go too far to the left with the values because, um, that either means that you're being too granular or you've got stories that are probably too big and they need to be disagregated. Now, somebody just chatted here. Um, should some buffer time be included in the actual estimates? Um, let me answer that question first by going back to ideal time and then I'm going to come back to story points and answer the question. When we're estimating in ideal time, we don't add a special amount of time that we would call a buffer. We just allow for the distractions and the interruptions, which could look like a buffer, right? You're saying you know um you know Priyanka if um based on your duties in the organization and our uh workday of 8 hours you're typically available to be doing your project work five out of those eight hours. So when we are converting ideal time to elapse time um you know we will be building in extra time based on distractions and interruptions. We would not call it a buffer, but that's essentially what we're doing. Now, when it comes to user stories that we're using story points, it is different. Um, the points are for the entire amount of the word. And why might we need to have some extra time for a user story? Well, it's likely going to be driven by uncertainty. There might be other uh things that impact it, but that's the main thing. Sorry team. So when the team is estimating the size of the user story, they will be including in their discussion and estimates any extra time or buffer time that would be needed for uh that user story to be completed. So do we accommodate um uncertainty when we're using story points? Yes, we're looking at the the X factor. And if we've got an unstable user story, then we're probably going to um say, you know, this is going to be a bigger user story than one that's similar but has a a much lesser level of uncertainty. Um so that's the story points. Let's compare the two. Um, ideal time uses things like hours and days, which is easier to explain outside the team, right? The suits like things in days and hours. Everybody's estimate may be different. Not a bad thing. It's easier to do at the beginning because we're oriented to think about time. Um, and it does kind of shine a light on wasted time. story points um are harder to explain outside the team. Um you know, the suit says, "Well, um how long is it going to take to do user story 301?" And our answer is, um well, that's a 10 user story point user story. And the suit's saying, "What does that mean? Tell me how long it's going to take." Um so the suits have to be converted to uh uh story points. Now, here's the thing. It's a lot easier to get consensus when we're estimating in story points. And once we get good at it, it's going to be much faster. We have to remember it's not comparable across teams. So, you know, a team working together will have its own kind of system for sizing the stories. And another team that might even be working on the same project will have a whole a whole different uh scheme. And so if the velocity of one team is 25 and the velocity of another is 50, it doesn't mean that the team with the velocity of 50 is able to do more work than the teams whose velocity is 25. And we did um when we got our day going um we started with um uh a planning poker exercise. And so you know we used all of the team members. So we selected the team, the product owner was there to answer any questions. Um the team discussed each of the story cards and then um decided what their vote was going to be and then everybody voted at once. If there were outliers, they were discussed and um the reasons for that uh those variances, those outliers um were then part of the discussion and then we did another round of voting. And we would keep doing that until we had our estimates converge or we reached consensus on them. Okay. So, advantages of planning poker, it's fun, it's quick, it gets the whole team involved, the the team understands um a little bit about all of the stories. Everybody contributes his or her expertise and the discussion during the estimation provides clarity in the direction approach and even a bit of design. If we were in the same room team and we were doing a planning poker activity like we did uh at the beginning of our day uh together um we would be able to you know model it a little bit better. Or if we tried to unmute everybody but you could hear the background noise. I've tried doing and it doesn't really work but you get the idea that if the team's discussing and things like that you would actually get to the point where um your estimates would converge and the team would say okay this user story size is you know whatever it is. Okay so we need to wrap things up for the day. So we are ending right here and that means tomorrow when we get together we're going to be doing slide 20 or starting with that which is affinity estimating and let's see affinity estimating. We go through that. We're going to talk about tracking progress using um information radiators and then we're going to talk about what we do when we find variances between the plan and the axle results and then we'll have our quiz. Now let's talk about the values of scrum. Now this is different than pillars. This is um values. So there are five um values for that and this is something that I want you to memorize. So, I'm going to switch my cameras here and go to the whiteboard and we're going to add to our list. Oh, wrong color. You can tell I'm a project manager because that would bother me. So the five values of scrum and there's an acronym you can see that on the screen right C force okay so five values of scrum and C F O R C. And you kind of know my style here. You don't have to do it this way. You know, whatever works for you, but have some kind of a strategy for memorizing things will probably serve you well. So the um the first C is commitment. The next one there are four. Four. F is focus. O is openness. Is that two N's or one? I don't know. Openness. We'll blame it on the marker if it's not right. Um R is for respect and the last C is courage. And so there's your little chart right there. And um let me just briefly go over these. Um none of these will be a big surprise here. Um we've talked about some of them already in one context or another. Um so the for commitment that means the commit the team is going to commit to deliver value to the customer. Um they're on board there's the buy in all of that's there focus the team is going to focus on the few important things um at a time. So we're going to do time boxing. uh we're not going to do things broadly. Specifically, uh focus on a few things at a time. O is openness. That's analogous to the T, transparency, and the pillars. Meaning, we're going to be completely open in sharing um information about the project, our own opinions, our fears, our concerns, etc. R stands for respect, and that's kind of a 360 view. We respect ourselves. We respect others. We respect the uh concepts that we are using as part of scrum and um um and you and we respect the other stakeholders as well. 360 and the last C stands for courage and that's the courage to make commitments uh even when we're in an uncertain environment. Um courage to deal with um fear that comes from a failure. Uh courage to uh share disagreements openly yet respectfully. Um courage to participate in debating technical approaches etc. Okay. So now let's go to the scrum life cycle chart. And what I want to do is I want to elaborate on this just a little bit. And I'm going to try and use my mouse to do some some uh additions to this. Um first of all, we have the product backlog. The product backlog has to be kept current and we call that grooming. Grooming is adding user stories and removing user stories from the product backlog. Product backlog is the scope of the project. The product owner owns that. The team assists in that effort. Related to grooming is pruning. Pruning the backlog is prioritizing and rep prioritizing. So the product backlog is pruned and groomed regularly throughout the course of the project. Now there is a meeting that takes place right here which is called the sprint planning meeting. Can I just do P SP here? Sprint planning meeting. Okay, that is one of the ceremonies or events that um takes place in scrum in the um the sprint planning meeting. It is a time boxed event and it is time boxed to 2 hours for each week of the sprint. So in our example here, we have a 30-day sprint. So if we have a 4-week sprint, then our sprint planning meeting will be 8 hours in duration. And two things happen during the sprint planning meeting. The user stories that are going to be included in the sprint are selected, right? they're put into the sprint backlog which is a subset of the product backlog containing the user stories that are going to be completed during the sprint. And the second thing that happens during the sprint planning meeting is the selected user stories are then disagregated into tasks and estimated. Once that's done, then the work of the sprint begins. There will be a daily scrum like we did at the beginning of our workday together as our team. And then at the end of the work of the uh sprint, there will be the sprint review. The sprint review meeting or ceremony is also time boxed and it is time boxed to one hour for each week of the sprint. So if we're doing a 4-week sprint, the sprint review meeting would be 4 hours in length. The primary purpose of the review is to showcase and demo the software and get feedback from relevant stakeholders and allow the product owner to say I accept or I reject the work that has been done. Then after that is the sprint retrospective. Now this is where the team asks and answers three questions. What went well? What did not go well? And what are we going to do different going forward regarding the previous sprint that was just completed and the ones that is is just coming up. Um and then the uh the sprint itself will result in working software or value for the customer. And then of course everything goes back and repeats for as many sprints uh as necessary to complete the scope of the project. Um let's see I see a chat here. How similar or different is the product backlog to SRS software requirement specs document which is widely used in projects. Um it's different. Um and if you will hang on to that question um we're going to have a discussion later on about user stories and that will help you understand uh the differences um and we'll get into the user stories that come from the customer and user stories that come from the tech domain and that will help answer your question. So you okay hanging on to that? Okay, great. Thanks. Okay. So, um a little bit more detailed view of the scrum project life cycle. Now, let's talk about a couple other things here. When it comes to um a sprint, there are some things that affect the duration of the sprint. So, the team is going to have to decide how long each of the sprints are going to be. And things that are a factor include the stability of the product backlog. If the product backlog is changing a great deal um then that's going to argue for shorter durations um because there's uh a high level of uncertainty and so you have a greater amount of control on your project if you have shorter sprints. Now on the other hand another factor is the cost of iterating. Every time we do a sprint, there are costs associated with the sprint planning meeting, the sprint review, the sprint retrospective, right? People show up to those meetings, you got to pay them. And um excuse me. So there there is an overhead cost to actually doing sprints. The goal of the sprint is working software. At the end, the end product should be near releasable or potentially shippable. Now, there might be working software that the product owner isn't going to want to release. Um, maybe because it as a standalone component of working software for the system doesn't create any value or any usability for end users. Uh, and maybe you wait till the end of a release before you release everything. But the idea is is it's working software and it could be released if um the customer wanted to do that. Um sorry I just dropped something. I see a question there. I will circle back to your question in just a sec. Um the sprint duration and deliverables do not change once the team has committed. This is another one of those things that has to be viewed as absolute when we're doing scrum. So if we say that we're going to do a two week sprint and we select five user stories based on our velocity or capacity. Once that decision has been made, the duration of the sprint does not change and we do not add or remove any user stories. Now it could be possible for the product owner to cancel a sprint but that would be extreme. That would be because there is such a major change to the product backlog that the work of the current sprint is going to be completely irrelevant. You don't change the sprint, you cancel the sprint. And then the bottom one here, the sprint begins with planning and ends with review and a retrospective. And there was a question here, are there any issues with combining the retrospective and the planning ceremonies? And the answer to that is yes. Now, could they be combined depending on the environment? The answer is yes. And the way we would arrive at whether or not it would make sense is who's going to be participating. Um, but they would be separate agendas. So the agenda for the retrospective is what went well, what did not go well, what are we going to do different? And the mandatory participants for that meeting are the the the team, the scrum team. Is the scrum master going to be there likely as a facilitator? Um, is the product owner going to be there? Maybe, maybe not. If the product owner is there, you know, the product owner could maybe answer questions and help clarify, but the product owner does not weigh in on what went well, what did not go well, and what are we going to do differently. That is all owned by the team. In the planning meeting, the product owner has to be there and the product owner is the main driver of that meeting. Um, the product owner is talking about or dealing with the priority of the user stories. The team's weighing in. Maybe there's some dependencies that need to be considered, but um the product owner has to make the hard decisions with regards to what's going to be done in the next sprint based on the constraints from the team like velocity um and technology and sequencing and things like that. So um I kind of answered that from a real world point of view. Yes, it could be. It's not desirable on the test. They are completely separate. Did I get you there? I'll keep my eye on the chat box. Make sure I got that answered well enough for you. And let's move ahead. Okay. The sprint planning meeting. This is uh looking right down here. This is conducted at the beginning of a new sprint. It's attended by the team, the product owner, and the scrum master. And there are two approaches to deciding what's going to be included in the sprint. It can be based on commitment and it can also be based on velocity. And the goal here is to get team buy in. Make sure that there is um clarity between the team and the product owner as to what the definition of done looks like for the user stories that are going to be included in the sprint. And um of course it should be realistic and achievable. And you know there can be a little bit of of um an issue where you've got you know a well-meaning product owner that's driving really hard and the team says you know we can do these sprints and the product owner is saying no come on you got to do at least one more. I got to have this one in this sprint. Um, you could get a question like that and it might be, "What would the scrum master do if you had a dominant product owner that's trying to persuade the team to do more than the team thinks it can do?" Um, and that's where the scrum master comes in. The scrum master plays the role of the mentor, the coach and uh, you know, assisting in the resolution of those kinds of issues without deciding. The scrum master is not a decider. The team decides uh when it comes to how and the product owner decides when it comes to what. Okay. The scrum meeting uh daily scrum we've talked about it right the entire team attends the meeting. Could the product owner be there? Yes. Does the product owner need to be there? No. Sometimes the product owner can be uh you know an impediment to the meeting. Um but would be welcome. But if the product owner started asking questions or became the focus of questions being asked, uh the scrum master would have to help facilitate a change because um that would not be effective for the daily scrum duration 15 minutes. We talked about that. And the agenda, what did I do yesterday? What am I going to do today? And what are my impediments? The sprint review. Now, who attends? it's going to be the team, the product owner, the scrum master and potentially others. So, optionally others, you know, that we would want to get feedback from would be end users, um, operations folks, the suits. Um all of those would be welcome depending on the relevance of the software that's being demoed and being um uh subject to the acceptance testing and the product owner you know giving the thumbs up or the thumbs down when it comes to acceptance. The duration for this we mentioned this before it's not just a flat two hours it's one hour per week. So if you did a 4-week sprint, you would plan on the review being a maximum of four hours in duration. The agenda is to demo the completed software, get feedback, and then see where we are when it comes to the the release plan, the retrospective, who is there, it's attended by the team. And I would modify this slightly and I would say this is the the mandatory group that needs to be there. Um optionally the scrum master would be there potentially you could have an external facilitator. The role of the scrum master would be the facilitator. Now um a good scrum master being a facilitator in a retrospective would have some knowledge of control charts, the five W's, um um Ishiawa diagrams, things like that. And although the scrum master would not be participating in the actual use of the tools, the scrum master would be facilitating the effective use of those tools. Um, when it comes to duration, the rule is 45 minutes for each week. Oh, that was a good four. That was kind of a lousy five. So, if you had a uh two week um uh sprint, then you would have an hour and a half retrospective max. And what's the purpose? There's uh the agenda for the retrospective. Three questions. What worked well? what did not go well? What are we going to do different? And it's not just a chat session. Well, that would be part of it. You will use tools and techniques um like some that I mentioned, control charts, um Ishiawa diagrams, um five wise. There's a number of things that you might use uh in order to surface uh assignable causes for issues so that we could then come up with a resolution to those. Um this is where continuous improvement um is uh going to happen. Um you know continuous improvement is the result of other things but this is the main thing and if you were get a question about the relevance or the necessity of retrospective there is no equivocation. you do a retrospective after every sprint. Um if you don't do a retros um if you don't then um there's no improvement. Um you know things just stay static. Okay. So we talked about the four main ceremonies right in uh a scrum project. Sprint planning you with me? Daily standup. the sprint review and then the sprint retrospective. All considered mandatory for effectively doing scrum and not doing them uh or one of them would be considered a fail. Okay. Artifacts that we use when it comes to scrum. Uh we've talked about the product backlog, we talked about the sprint backlog. There's also um a release backlog. Uh depending on the size of the project, it might be advisable to uh group user stories into releases. Um if you have a product road map, uh your releases would line up for that. Um, for example, I've got a um uh a real life project that I'm working on and my product road map is um uh got three versions. It's a website. Um the first uh version is free. Uh the second version includes a membership component and the third uh version includes um a referral commission uh portion to it. And so I will then uh do three releases. I'll have all the user stories that will result in version one, all the the user stories that re result in version two. So that's what the release uh backlog is. And so if you look at it in sequence, the product backlog is the overall scope of the project. The release backlog is a subset of the product backlog. And then the sprint backlog would be a subset of the release backlog. The product backlog might look something like this. Um, it's a list of user stories that are written by the product owner and are going to be developed by the um team members. And didn't we have we had a product backlog for the thing that we did this morning, right? So, here's another example of a product backlog. Um, this is more of a list. Um, and it just has the title. There would be a user story card for each of the items in the product backlog. Um, but the idea would be it would be prioritized. Uh, there could be user stories that are added or removed depending on what the product owner wants. Product owner owns the product backlog. Um, that's a given. Uh does the product owner create all the user stories for the product backlog in isolation? No, absolutely not. Because there are technical considerations that the product back or the product owner might not um even consider. The product uh owner's perspective is more the customer side, the enduser side. Um and so the product owner might not even think of things like security or architecture related things. Um and there might even be uh user stories that come from the technical domain that need to be uh developed before some of the uh products owners user stories. Another artifact is the definition of done. The definition of done is primarily a checklist and this is what forms the agreement between the product owner and the team um as to when we consider something completely done. And if we look down here it's um uh where's my I'm looking for my cursor. It says here it's usually prepared by the scrum master in consultation with the team. Um that is I would modify this slightly. Um the definition of done is really driven by the team. The see the scrum master is never a decision maker. If you have a scrum master that's saying we have to have this in the definition of done then that's an infringement on the empowerment of the team. I agree that the the scrum master is a part of the effort to develop the definition of done. Um but I would kind of flip that. Uh the scrum master is the facilitator. It's the team that still um owns that. So um now is the product owner involved in this? Absolutely. Because the product owner is involved in defining the story and what a fully implemented story looks like. So, here's a list, a short list of what a definition of done could look like. The story has been fully implemented or the code completed as described. Um, automated unit tests have been developed with at least 80% code coverage. Um, it could be more than that. Um, this is just an example. Automated unit tests and acceptance tests of the story are passing. no severity has one or two defects and then high priority test cases have been automated and added to the regression suite. Um the definition of done we point out is likely to evolve as the team's maturity increases as the project advances. There are three distinct roles in scrum. the scrum master, the product owner and the development team. The scrum master assists both the development team and the product owner. The scrum master works with the product owner to maximize return on investment. The scrum master empowers the development team by fostering creativity, removing impediments and coaching and mentoring as appropriate. The product owner is responsible for project success by defining the project vision, requirements, and priorities. The product owner has to resist the temptation to manage the team or add more important work after a sprint has begun. The product owner has to be willing to make the hard choices during sprint planning. The development team is comprised of five to nine members with a mix of roles and has the autonomy to self-organize and choose how best to meet the goals of the product owner and is responsible for the same. A scrum master is a skilled servant leader. A scrum master has very little formal authority. However, he or she is expected to assist the team achieve the intended outcomes without interfering with the team's autonomy. The scrum master facilitates the scrum ceremony such as sprint planning, daily standup, sprint review, and sprint retrospective. The scrum master removes obstacles or impediments faced by the team. The scrum master is also a process coach and mentor. The scrum master must not be a line manager of the team. The scrum master is not to be a taskmaster either. The scrum master is not a technical or design authority. Nor is he or she a decision maker for the team. Throughout the course of the project, the scrum master must not do anything to rob the team of its empowerment and ability to self-organize. Let's talk about the attributes of a scrum master. Scrum masters need to exhibit responsibility even though they are not solely accountable for the team's output. They will consider it their responsibility to remove anything that impacts the team's productivity. They will try to enable the team to do the best that it can. They are humble. They will work in the background and let the team take all the glory. They will use we statements and seldom use any I statements. They are able to set aside their ego and shower all their attention on the team. They are by nature collaborative. They will encourage the team to have conversations among each other and with other stakeholders outside the team. They will nudge all the right people into getting involved and work together in trying to solve problems. They are committed to the team cause. Even if being a scrum master is a part-time task for them, they will give the highest priority to the team's needs. Hence, the scrum master's work allocation, especially if they are part-time, needs to take this into consideration. They are able to influence. They are naturally good communicators and able to convince others to adopt different approaches. They apply various techniques to mobilize organizational resources when required, walk the political tight rope when required, and in general do whatever it takes to get the team the assistance it needs. They are knowledgeable. It is clear that as process coaches for the team, scrum masters need to be experts in the method. They may not be the technical or domain experts. However, they are knowledgeable enough to be able to have productive conversations about the project being done by the team. Tasks for the scrum master. The scrum master is a crucial role and it is important for you to be able to be clear about exactly how the scrum master serves the team. Scrum masters are servant leaders. This means that they put the team before themselves and assist the team. For example, they set up ensure that the scrum ceremonies are effectively carried out. They ensure that there is smooth flow of information within and outside the team and that there is a spirit of collaboration in decision-making and problem solving. Scrum masters must make it their mission to resolve issues that hinder team progress. It doesn't matter what the nature of the issue is. A scrum master needs to mobilize the right resources within the organization to resolve those issues in a timely manner and escalate promptly if that does not happen. We need to understand that in the short duration of a sprint even a few hours of being stuck can make the difference between a successful and unsuccessful sprint. Scrum masters protect the team. They ensure that the team is not disturbed or asked to deviate from their commitments. If pressure mounts due to unreasonable expectations, they will step in and push back on the team's behalf. They will also play the role of peacemaker when conflict arises by encouraging the parties to focus on the issue, discuss the issue with an open mind and resolve the conflict. Finally, scrum masters are the process coaches of the team. They use their understanding of agile methods and scrum in particular to guide the team through the dos and don'ts of scrum. They ensure that the team stays true to the principles of agile development. Scrum master roles, scrum teams. Before we discuss the role of a developer on a scrum team, let's talk about the desirable characteristics of scrum teams. They should be small and nimble. Team size should be no less than three and no more than nine. So that would be six plus or minus three. Exceptions are possible but uncommon. The small attribute makes the team nimble and improves productivity. It avoids the phenomenon Mike Con calls social loafing and instead produces focus on work. The team size should be just large enough that the team members are able to produce and showcase a significant increment of work at the end of each sprint. Sprint after sprint. Self-sufficient and crossfunctional. For example, if a team needs user interface development skills, database expertise, and service expertise, all of those skills must be present on the team. Ideally, team members are generalizing specialists. Team members should not only be an expert or a specialist at one aspect of the development effort, but should also have enough skills and knowledge to fill in in other roles as necessary. For example, if you are a UI developer, you should be able to dawn the hat of a services developer if needed. If a large team is to be split up into smaller scrum teams, scrum favors feature teams over component teams. Autonomous and self-organizing teams choose for themselves how they are going to organize and meet the goals of the product owner. No one gets to dictate to the team how to get their work done. The team decides in collaboration with the product owner the project direction and the pros and cons of different approaches. Let's talk about some key decision points or factors to consider when assembling scrum teams. Feature teams over component teams. The first issue is whether it's best to align team members based on features or components. Scrum favors feature teams over component teams. For example, it's best to avoid putting all of the UI developers together and all of the API or services developers together. Why? Because each feature or user story will require both the UI and services or API. Organizing based on components will reduce the incentive to collaborate. The only reason component teams may be justified would be if the components are likely to be used by multiple other teams. Assemble the right people. It's important to get the right mix of people together for the team. The right level of technical and domain expertise. Teams will naturally have both senior and junior level developers. This works perfectly as there will be stuff that is more appropriate for the junior developers and stuff that is not. Also, one of the risks of a small team is that the team may miss out on broader perspective and dissenting views. One way to work around this is to deliberately favor diversity in all aspects, gender, ethnicity, personality traits, etc. It may take some time for the team to advance through the storming stage of teen development and develop the trust necessary to work effectively together, but it can be done. Once a team has been formed, it's best to preserve and assign whole teams rather than individuals to projects. It's best to avoid assigning team members to multiple projects at the same time. Distributed team. A distributed team may be unavoidable. Those based at the same geographical location should be colllocated in the same team room and technology processes and ground rules should be put in place to overcome the disadvantages of all team members not being colllocated. Plotting team size and productivity will likely result in an S-curve. You can see here that a team can actually be too small or too large. Remember the sweet spot is six plus or minus three. Think of scrum as a lightweight framework that utilizes principles and practices that assist teams in delivering working software in short cycles to the customer enabling rapid feedback, continuous improvement and quick response to change. It promotes delivering value as in working software to the customer in an incremental and iterative way. It is not a process or technique for developing software. Rather, it is a framework within which various processes, techniques and practices are employed. In scrum, the iterations that deliver working software to the customer are called sprints. in each iteration or sprint results in potentially shippable software. This slide is a graphical representation of an agile project using scrum. Starting at the left, you can see that the product owner owns the product backlog and in collaboration with the team develops the user stories or requirements for the project. The product backlog is prioritized with the higher priority items occupying the top of the product backlog. In collaboration with the product owner, the team decides how to group the user stories into releases based on the product roadmap. Once the release planning has been completed, the user stories are then selected for a sprint. The duration of the sprint is going to be two to four weeks. Once the sprint backlog has been determined, the team then disagregates each user story into tasks. During each sprint, the user stories are developed. As the code is written, it is integrated into the system and daily scrums are held. At the end of a sprint, there is a sprint review where the working software is demonstrated and presented to the customer for acceptance. The team then conducts a sprint retrospective. During the retrospective, the team looks at primarily three things. What went well, what did not go well, and what should be done differently going forward. The team's velocity is then updated as are the information radiators which transparently display the status and progress of the project and then the cycle repeats itself until the project is complete. A sprint is an iteration in scrum. At the beginning of a project, the scrum team determines the duration of sprints for the project. Most sprints are going to be two to four weeks in duration. Factors affecting sprint duration include the stability of the product backlog. Once a sprint has begun, the duration is never changed, nor are any user stories added or removed. Therefore, if many changes are expected, a shorter sprint duration would be best. However, if the product backlog is relatively stable, a longer sprint duration may be appropriate. Overhead. There are overhead costs associated with each sprint. For example, every sprint's going to have a sprint planning meeting, a sprint review, and a sprint retrospective. If a team has been able to lower these overhead costs by automated testing, continuous integration, etc., These costs can be absorbed more easily, making shorter sprints more desirable. However, if these overhead costs remain high, the team may need to use longer duration sprints. A team may be tempted to extend the duration of sprints in an effort to hide their inefficiencies. Remember, agile projects favor shorter duration sprints, and it is the scrum master's responsibility to coach and mentor the team so it can reduce waste, irregularities, and overuse and make the sprint shorter. The goal of a sprint is to deliver working software. At the conclusion of each sprint, the team should be able to deliver nearreleasable or potentially shippable software. This is not easy, especially for an existing product with a lot of legacy features, but it can be done with the right technical practices and mature development processes. Once the sprint duration has been determined and the user stories for the sprint have been selected, the duration of the sprint cannot be altered, nor can any user stories be added or removed. The sprint will end at the appointed time irrespective of whether the team has met the sprint goals or not. This allows for effective continuous improvement. If the team is unable to deliver the working software as planned, the team will have to figure out why that happened and then make changes to improve going forward. The product owner may choose to cancel or terminate a sprint in specific situations. For example, a significant change in priorities or a midcourse correction may render the current sprint backlog invalid. Given that we are only talking about a couple of weeks of work, the cancellation of a sprint would be an extremely rare event. A sprint will begin with a sprint planning meeting and end with a sprint review and retrospective. There are three backlogs used in Scrum. The product backlog, the release backlog, and the sprint backlog. The product backlog is the master container of all the user stories for the project. The product backlog is continually pruned or prioritized so that maximum value is delivered to the customer. The release backlog is a subset of the product backlog. Releases support the product roadmap and each release is populated with user stories necessary for that release. The sprint backlog is a subset of the release backlog and contains the user stories to be developed in the sprint. As we said, the product backlog contains the user stories for the entire project and it is the responsibility of the product owner. User stories are features, functions or requirements that deliver value to the customer. However, the product backlog will also have to contain technical or nonfunctional user stories necessary for the system to work properly. The product backlog may also include risk or defect related user stories. The product owner is responsible for keeping the product backlog current and up to date. This is accomplished by pruning the backlog which is prioritizing and rep prioritizing. The product backlog must also be continually groomed. This is the process of adding and removing user stories based on the needs and desires of the customer. There are four scrum ceremonies. The sprint planning meeting, the daily scrum, the sprint review, and the sprint retrospective. Let's take a detailed look at each of these ceremonies. The sprint planning meeting is time boxed at two hours for each week of the sprint. If the sprint is going to be two weeks in duration, then the time box will be four hours. If the sprint is going to be four weeks in duration, then the time box for the sprint planning meeting will be eight hours. It should be attended by the complete scrum team including all roles. The most important aspects of this meeting are the team's capacity and the definition of done. There are two approaches to selecting user stories for a sprint. One is based on the velocity of the team. The other is commitment driven. Team buyin is critical and the goals of the sprint should be clearly understood and the desired outcome should be clearly articulated with the definition of done. Then there's the daily scrum. The time box for the daily scrum is 15 minutes regardless of the duration of the sprint length. The entire scrum team including all roles should attend the daily scrum. Each development team member individually answers three questions. What did I do yesterday? What am I going to do today? And what are my impediments? This is how the team members coordinate their work and the scrum master learns of the impediments he or she should be taking care of. The sprint review takes place at the end of the sprint and is time boxed at one hour for each week of the sprint. So if the sprint were four weeks in duration, the sprint review meeting would be four hours. It should be attended by the complete scrum team including all roles plus any other stakeholders who are interested in project success. The purpose of the review is to demonstrate working software and obtain and assess feedback. Feedback may range from full acceptance of the completed software to complete rejection. The sprint retrospective takes place after the conclusion of the sprint review and is time boxed at 45 minutes for each week of the sprint. So if the sprint has two weeks in duration, then the retrospective would be one and a half hours in length. It should be attended by the complete scrum team including all roles. However, the product owner's attendance is considered optional. During the retrospective, the team answers four questions. What worked well? What did not work well? What should be done differently? And what still puzzles us? One or several problem detection techniques may be used in the retrospectives. And this ceremony is a vital part of continuous improvement. At the conclusion of the retrospective, the team's velocity and the project's information radiators are updated. Then the next sprints planning meeting takes place and this cycle continues until the project is complete. The definition of done is an important artifact for a scrum team. It is the primary reporting mechanism for team members and there may be a different definition of done at various levels. definition of done for a feature or user story, the definition of done for a sprint, and the definition of done for a release. It's really just a checklist of activities that add verifiable and demonstrable value to the product. It's created by the scrum master in consultation with the team. A sample list of the items for the definition of done criteria is given here. The story is fully implemented or code completed as described. Automated unit tests have been developed with at least 80% code coverage. Automated unit tests and acceptance tests in the story are passing. High priority test cases have been automated and added to the regression suite. Note, this is only meant to be an example. Each team's definition of done will vary slightly depending on the maturity of the team and the specific situation of the team. The product team has taken up a new project called weathermaster. The team is planning to move to scrum methodology and this is an outline of its first scrum meeting time box to 15 minutes. Rick is the scrum master of this meeting where the team members discuss what they did yesterday, their plans for today, and the impediments they faced. All team members are standing up, including Todd, who's joined the meeting via video chat. Rick holds the meeting near a scrum board. Angela, the product owner, is absent. Rick reiterates that all discussions would be parked until after the scrum meeting and encourages his team to keep the meeting short. People can chime in to resolve obstacles. Hi team, welcome to the daily stand-up meeting for the product team on project weathermaster. We are in sprint one and today is the second day. As we are planning to transition to scrum methodology, I hope you will find this daily stand-up meeting helpful. In this meeting, you will provide information about what you did yesterday, what you plan to do today, and what challenges you faced. I think everyone's here. Let's start. I don't see Angela. Shouldn't she be here? I did add Angela as an optional attendee to this meeting. And since she hasn't showed up, we don't have to wait for her. Susan, scrum doesn't provide a specific yes or no about the product owner's participation in the daily scrum. The PO's primary role is to provide direction and clarify requirements and priorities. Since we don't always discuss those in detail at this meeting, the PO is not required to be here. If the POSs want to attend, they are generally in listenonly mode for the duration of the meeting. They can use the information gathered during the meeting for separate offline conversations. [Music] [Music] What about Todd? He works from his home office, right? Todd will be a part of the meeting through video chat. It is important that we include every team member in the meeting. Hi Todd, how are you? I'm fine, thanks. Am I audible? Yes, Todd. Team, let's all stand up for the meeting. [Music] [Music] Why don't you go first, Aaron? Yesterday, I was working on creating the mock objects to mask the database calls from the unit tests. The difficulty with this approach is that our server side logic is so dependent on the metadata that writing a true mock is a mammoth exercise. There are decisions that are taken during runtime based on the data. Some of the stored procedure calls are also made based on the values returned through inline queries that are also embedded in the code. I was debugging the code until about 9:00 p.m., but for the life of me, I couldn't figure this out. Aaron, could we request you to be concise when you provide an update? If you think some of the details you describe might be interesting to others, why don't you write a wiki page on it and share the link? So, getting back to your update, did you finish the task yesterday? No, it turned out to be much more complex than I had imagined. I'll continue to work on it today and see if I can figure out an XML structure to mock the schema and hardcode some return values. But I am really stuck as far as the inline queries are concerned. I know what you're talking about. There is a reason why the inline queries are there in the code. This is mainly for performance reasons when the overheads of making a procedure call based on a metadata value and then processing the Sorry for the interruption again guys. This is a really great conversation. May I suggest we write this issue in the parking lot? I'm not sure what you mean by that, Rick. Let me explain. What Aaron just brought up is a blocking issue. Team members should bring these up during the daily scrum so that everybody knows that one of the team members is stuck. However, the daily scrum is not necessarily the meeting where solutions to every obstacle can or should be found. It looks like Mary knows a thing or two about the issue that Aaron has brought up. Let's jot this down as a parking lot topic. This means the team can have offline conversations after the daily scrum to track it down. I'm also going to make a note that we'll track the impediment Aaron faced daily until it is removed. You should let me know if I can help in any way, right? Aaron, is there anything else you would like to say? No, I am done. Thanks. Yesterday, I worked on developing the wizards for bulk order creation. I'm almost done. Today, I need to write code to handle some of the exception scenarios before I can get them over to Susan for testing. That's it for me, I guess. Did you forget to mention any impediments? Not really an impediment at present, but I would like to mention that my computer probably needs to be upgraded with more RAM. It has been slow for the past few weeks. Okay, I wrote up some scenarios to test the bulk order wizard. I'm looking to get my hands on the code as soon as Mary is done today. I'm also hoping to complete the company order testing that has been pending for a while. I'm okay for the moment, but I do have one question. Shouldn't we all be updating the task board as we speak? We could. It is up to you guys if you think you want to do this during the meeting. If you ask my opinion, we should update the board as soon as we are ready to move the tasks and not wait for the meeting. This will ensure that the board is always up to date and also that we use the meeting time to focus on the conversations. That's a great point, Rick. I can't see the board very well from here anyway. So maybe we should find a way to create an electronic version of it too at some point. Great point, Todd. Why don't you go next with your updates? All right. Hey, Rick. Would you like to know about my work on the advertising module first or the integration server? Whatever the team decides is fine with me. Remember, this is really your meeting, and I'm only here to facilitate and ensure we get the most out of this meeting. [Music] [Music] All right, then I guess I'll start with the integration server. I would like to inform everybody that I managed to set up the integration server that we can use as a sandbox to test the code before checking it in source control. I'll send everybody a link with some instructions and credentials. I have also started looking at the stories for the advertising module. It looks like there are a lot of open statements in the stories that I don't really understand. I guess I should have been paying more attention during the sprint planning. I really need to have a conversation with Angela about this. That is my main impediment right now. I sent her an email, but haven't received a response yet. I don't have anything new to add today. I'm almost through with setting up our project on the freeware tool that I downloaded yesterday. I'll show you guys a demo in the meeting I set up later today. I'll try to chase down some of these parking lot items. Anything else before we close the meeting? All right, that's it for today. Have a great day. Do you have a moment to chat about the inline queries real quick? The purpose of a scrum meeting is to keep the team members updated and resolve any impediments. It's an ideal way to kickstart the day on a positive note. The scrum master reinforces the sense of the self-managing team, facilitates communication between team members, brings the team's focus back to what's important, and supports improvement. So before we dive into the differences between scrum and canban, let's have a look at what exactly scrum is. Scrum is a simple agile project management framework that is used by organizations to help teams collaborate, handle unpredictability and complex projects or products while ensuring the products delivered are of the highest value. It describes a set of meetings, tools, and roles that enable teams to work in sync and help them structure themselves and manage their work. Scrum is one of those things that's really easy to understand, but very difficult to master. And although Scrum is seen to be used generally by software development teams, its principles and themes are pretty universal and can be used with just about all kinds of teamwork. With Scrum, teams are able to learn from their experiences, what worked out, what didn't, and things like that. They're also able to organize themselves to handle their problems effectively and basically improve themselves by reflecting on them. So, how does Scrum work? Here we have the first component, the product backlog. The product backlog consists of a list of tasks that need to be completed so that the goals of the stakeholders are achieved. Then the team decides what tasks from the product backlog they want to take up and deliver in a 2 to 4 week period called sprint. Hence the name sprint planning. Next, the tasks that were discussed in the previous phase are added to the sprint backlog. This is a set of tasks which will be focused on in the ongoing sprint. Following this, the scrum team, which is usually 5 to nine members strong, will work on these tasks. Now they also have regular scrum meetings where they talk about their victories, the issues they face and what they plan to do in the next 24 hours and then they have the sprint review. The sprint review is a meeting during which the team shows what they accomplished during the sprint. Now during this time questions are asked, observations, feedback and suggestions are made. The product owner also gets feedback for upcoming sprints from stakeholders. They also have a sprint retrospective. Now during this session, past mistakes, potential issues and new ways to handle them are identified. Data from here is incorporated into the new sprint plan. The final step is increment. Here a workable and usable output is provided to the stakeholders. So now that we know how scrum works, let's have a look at canban. Canban comes from the Japanese word canbam which literally means signboard. Like scrum, canban is a popular agile framework that is a visual system by which the work can be managed with ease as it progresses. Canban uses something known as the cananban board to make these things possible. With this you can easily identify bottlenecks and then fix them cost effectively at optimal speeds. The main focus with Cananban is transparency. Since everything related to the tasks are on the board, everyone can keep themselves updated. It also ensures the team's focus on their current tasks until they're done. This limits the amount of work that's in progress. So on the cananban board, work is divided into smaller, more manageable pieces. The work that's needed to be done is written on a note or card and placed on a board. Columns on the board help represent where each item is with respect to the workflow. Now let's have a look at what these are in detail. Let's find out how canban works. Now, the board consists of three major components. There's the to-do list, which represents items that need to be completed, the ongoing column, which represents items that are being currently worked on, and the completed or the done column. Now, these represent tasks or items that have already been completed. Now, although this is a physical representation of the board, several organizations use software versions of the board that replaces the sticky notes with cards that can be moved from one column to another as work progresses. Now, an example of such a software is Trello. So, if you want to learn more about Trello, you can check out the link I'll be adding to the live chat in a moment. At this point, you guys must have realized how similar these two frameworks sound. So, let's run through some more of their similarities. Let's find out how they are similar. Firstly, they both have principles of lean and agile which means reduction of waste and both of them are timeboxed and iterative approaches that enable product delivery in an incremental manner. Both these frameworks aim to reduce the amount of work in progress. This forces the teams to ensure that they focus on a smaller set of tasks. This also makes blockers and bottlenecks a little more visible. In both cases, the work is divided into smaller, more manageable units. Both of these frameworks use pull shoulduling. Now, this means that products are only built based on demand rather than forecasts. Transparency plays a major role in both these frameworks by helping them drive process improvement. And in both cases, the release plan is continuously optimized. And finally, both these methods aim to deliver releasable software often and earlier than expected. So now that we've reached midway, let me ask you guys a question. Do you guys use scrum or canban in your workplace or do you use these software for personal reasons? What exactly do you use these for? Let me know in the live chat. Now let's have a look at how these two frameworks are different from one another. Firstly, let's have a look at cadence. Cadence refers to the amount of time in a sprint or before a release. So when it comes to scrum, the entire project is divided into time constrained iterations that is into smaller manageable units. But when it comes to canban, it's event driven. The next criteria we're going to have a look at is release methodology. In scrum, releases take place after each sprint, which usually takes 2 to four weeks to complete. For canban releases take place in the form of continuous delivery. They happen in such a way that changes like new features, configuration changes, bug fixes and experiments get to the users in a safe, quick and sustainable manner. Next up, let's have a look at how changes are addressed in both these frameworks. In Scrum, no change can be made while the sprint is in progress. Once it's complete, changes can be considered in the sprint plan and then added to the sprint backlog. With Canban, changes can be made at any time and incorporated into the workflow. Now, let's consider the metric that's being measured in scrum. For planning and process improvement, velocity, which is the measure of the work that can be completed by a team in a sprint, is the key metric. In canban, lead time is the key metric. This represents the period of time between a new task's appearance in your workflow and its final departure from the system. Next, let's have a look at how teams work in these frameworks. In scrum, you need a crossf functional team to achieve your goals in a sprint. In canvan, cross functional teams are optional, but specialized teams that focus on particular aspects of the workflow are required. Now, let's talk about new additions in scrum. Just like handling changes, you can't add any items between a sprint or an iteration. In cananban, new items can be added to the board as long as there's capacity available for it. Now let's have a look at the job roles within these frameworks. Scrum has three major job roles. Product owner, scrum master, and scrum team. With cananban, you don't have any specific job roles. Now let's talk about representation or moreover let's talk about how data can be represented with scrum the board needs to be reset once a particular sprint is complete with canban the board stays persistent throughout the entirety of the project and finally let's have a look at project length with scrum it's better suited for longer projects and with canban projects that can be completed in a shorter period of time are better. Introduction to agile manifesto. The agile manifesto is a seminal document in the field of software development created in 2001 by 17 software developers who sought to outline a more flexible and efficient approach to project management and development. It emphasizes individuals and interactions, working software, customer collaboration, and responding to change over traditional processes, documentation, contract negotiation, and plan following. This manifesto has since become the foundation for agile methodologies, promoting a flexible team oriented approach that values adaptability and customer satisfaction above rigid adherence to plans. With the manifesto in mind, let's start exploring the the four core values of agile. The four core values of agile focus on people and results rather than rigid processes. Individuals and interactions over processes and tools. Prioritizing teamwork and communication above strict adherence to tools and processes. Imagine a team deciding together how to solve a problem instead of just following a manual. It's like choosing a group discussion over filling out forms. Working software over comprehensive documentation. valuing functional software that meets user needs over detailed paperwork. Think of it as cooking a meal that tastes good and serves its purpose rather than writing a detailed recipe book before the meal is even made. Customer collaboration over contract negotiation, emphasizing ongoing engagement with customers rather than sticking strictly to initial agreements. It's like working with a home builder who listens and adapts to your changing needs during construction instead of sticking strictly to the original plan. Responding to change over following a plan. Being open to change and adapting plans as needed instead of rigidly following a set path. Picture a road trip where you're open to taking a more scenic route based on new information rather than sticking to the fastest route Google Maps suggested initially. These values guide the agile methodology towards flexibility, efficiency, and customer satisfaction. The 12 principles of agile software development. The 12 principles of agile software development as outlined in the agile manifesto advocate for customer satisfaction through early and continuous software delivery. Prioritizes getting a functional product to the customer as soon as possible, then updating it regularly. Example, a team releases a basic version of an app to meet initial user needs, then adds new features based on feedback, welcoming changing requirements even late in development. It is time consuming to handle large and complicated work when managing project activities. Therefore, a better strategy is to break the task into manageable sizable chunks. In addition, it would be simpler for the team members to see possible bottlenecks and deal with delays if the clients were always kept informed. For example, if users need a new feature because their needs have changed, the development team works to incorporate it even if it wasn't in the original plan. Frequent delivery of working software. According to the agile methodology, working software is frequently delivered in a shorter amount of time. Team members must consistently raise their performance standards as a result of this iterative process. For example, delivering updates every two weeks to continuously improve and adjust the software based on user input. Business people and developers must work together daily throughout the project in order to ensure that the business and development sides of the project can communicate effectively and more importantly collaborate. A bridge between them must be built to facilitate an intellectual exchange that both parties can agree on. Make use of the same tools you would have used in managing remote teams. For example, regular meetings between the client and the team to discuss the project's direction and adapt as necessary. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. The project manager must establish a supportive and stimulating environment where team members are free to express their ideas and make recommendations for enhancing the output of the group. This results in a massive improvement in their general performance eventually aiding the project. For example, allowing a developer to choose their tools or method of working to solve a problem can lead to more innovative and effective solutions. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Efficient communication among the parties concerned is stressed strongly in the agile manifesto. Thanks to improvements in communication technologies, it's now simpler. Instead of having a quick conference in the office, all participants can now meet via video conferencing. For example, solving misunderstandings or clarifying requirements through direct discussion rather than through emails or reports. Working software is the primary measure of progress. Delivering a functional product that pleases the consumer is the single determinant that can guarantee success. Before agile, numerous success metrics decreased the quality of the finished product. For example, a team focuses on delivering a basic but operational piece of software first rather than ensuring every document is perfect. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Burnout will occur if you work on a project for a long time. It's inevitable. Avoid placing too much of a workload on your employees. The value of your project will be affected. So, assemble the best team for the job that will work hard but refrain from overworking themselves and endangering the project's quality. For example, instead of pushing for long hours to meet an unrealistic deadline, the team sets a realistic timeline that allows for steady progress without overtime. Continuous attention to technical excellence and good design enhances agility. Any agile team's main goal should be to provide value to the client. Therefore, a multi-skll team that can manage all the project's technical components and offers the chance for continual improvement is crucial. For example, regularly refactoring code to improve its structure without changing its external behavior. Simplicity, the art of maximizing the amount of work not done is essential. You should avoid adding extraneous complexity to a project if you want to complete it swiftly. You can accomplish this in various ways including by using agile tools which eliminate busy work and offer you more significant influence over all project related decisions. For example, developers decide not to add a feature that only a few users would use, keeping the system more straightforward and easier to maintain. The best architectures, requirements, and designs emerge from self-organizing teams. simply said, "A self-organized workforce with decision-making autonomy would function better since each team member would be responsible for meeting client expectations rather than a lone project manager. For example, a team decides who will work on what tasks based on each member's strengths and current workload rather than having a manager assign tasks. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile techniques are constructed on the notion of iteration where teams consistently enhance their game by learning from their previous wrongdoings. Project managers should inspire team meetings where everyone evaluates their work and discusses how to develop their management and technical skills. For example, at the end of each development cycle, the team needs to discuss what they can change to work more efficiently in the next cycle. with core values and principles in mind. Let's have a look at implications of agile values and principles. The implications of agile values and principles revolve around fostering a culture of flexibility, collaboration, and continuous improvement. They lead to enhanced adaptability to change, allowing teams and businesses to respond swiftly to market shifts and customer needs. Increased customer satisfaction by prioritizing customer feedback and delivering value early and often. Improved product quality through iterative development and a focus on technical excellence. More efficient and motivated teams due to empowerment and a focus on individuals and interactions. These points underline how adopting agile can transform organizational workflows and outcomes. Now let's see some real world applications of agile. Innovation in tech. Companies like Spotify utilize agile to foster innovation, rapidly testing and deploying new features. Adapting to market changes, Netflix applies agile principles to quickly adapt to user preferences and technological advancements, maintaining its market leader position. Banking sector agility. Banks have adopted agile to improve their digital services, making customer transactions smoother and more secure. Healthcare efficiency. Agile methodologies help healthcare providers streamline operations and improve patient care through faster, more responsive services. Manufacturing flexibility. Even in manufacturing, agile enables companies to respond swiftly to market demands and supply chain challenges. And there you have it folks. So without any delay, let's get started with the scrum master interview questions along with the answers. So first question is what is scrum? And here is the answer. Scrum is an agile framework that can help teams work together. Scrum can enable teams to learn from experiences, self-organize while working on problems, to reflect on their victories and failures to make improvements and much more. It is basically a starter question to keep the interview going. Now moving on to the second one is differentiate between agile and scrum. So they are basically asking you to differentiate between agile and scrum. So you need to provide them the differences and here you go agile. Agile is a set of principles that's iterative and incremental in nature. Whereas scrum it is an implementation of the agile methodology itself. Agile it is suited for the projects involving a small team of experts and scrum it is used in teams that need to handle constant changing requirements. Under agile again the project takes care of all the task and is vital to the project and here in the scrum there is no leader basically the issues are handled by the scrum master and the team. Then again under agile we have changes cannot be handled frequently and in scrum the teams can react to changes quickly and in agile again the lastly we have it requires frequent delivery to the end user and in the scrum it sprints provide the workable builds of the final product to the user for feedback. Now moving on we have define the various roles of scrum and here is the answer. There are basically three roles. The product owner, the scrum master and the scrum team. So what do you mean by product owner? The product owner is an individual who is responsible for increasing the ROI by determining the product features, prioritizing these features into a list, what needs to be focused on the upcoming sprint and much more. These are the constantly rep prioritized and refined. Coming to the scrum master, this individual helps the team in learning to apply scrum to ensure the optimum business value. The scrum master removes embedments, shields the team from distractions and it enables them to adopt the agile practices. Then again coming to scrum team, they are the collection of individuals who work together to ensure that the requirements of the stakeholders are delivered. Now moving on, we have what are the artifacts of the scrum process. So here you go with the answer. So there are basically three artifacts. The product backlog, the sprint backlog and the product improvement. The product backlog is a list that consists of the new features, changes to features, bug fixes, changes to the infrastructure and other activities. Coming to the sprint backlog, it is a subset of the product backlog that contains a task focused on by the team to satisfy the sprint goal. The coming to product increment. It is a combination of all the product backlog items completed in a sprint and value of the previous sprints increments. And like this you can frame your answer. Now moving on we have how are the product and the sprint backlog different from each other. And here is a list of differences. Now differentiating them as a bench of definition. The product backlog is a list of items that need to be completed for developing the product and the sprint backlog. It is again a list of items to be completed during a specific sprint. Now coming to the sources then product backlog is collected from the customer by the product owner himself and assigned to the team. The sprint backlog is collected from the product owner by the team for a specific sprint. Now differentiating them on the basis of scope, goal, time frame and ownership. Now moving on to the next question is who is a scrum master and what does he or she do? And here is the answer. A scrum master is someone who promotes and supports the usage of scrum within the team. He or she understands the theory, practices, rules and the values of the scrum. He or she even ensures that the team follows the values, principles and the practices of the scrum. They remove any distractions and impediments that hamper the progress of the report. The scrum master ensures that the team delivers value during the sprint. Now moving on to the next question is what happens in the daily standup sessions and here is the answer. The stand-up sessions are basically the daily discussions that take place and are usually 15 minutes long. So it helps us understand what task went well, what tasks were completed before and what tasks are pending and the obstacles the team is facing in delivering the product on time. So the meeting basically helps in understanding the overall scope and the status of the project. Now moving on to the next question, we have what is scrum ban? And here is the answer. Scrum ban is basically a hybrid of scrum and canban designed to suit the team's needs. It reduces the work batching and uses a pullbased system for task management. It combines scrum structured approach with canban's flexibility and visual workflow offering the best of both the worlds. Now moving on we have what are sprint zero and spike and here is the answer. Spend zero refers to the small amount of effort put into create a rough skeleton of the product backlog. So it includes insights towards estimating the release of the products. So the question may arise why it is required. So you can tell like it is helping in creating the project skeleton along with the research spikes. It helps in keeping the minimal design developing some stories completely from scratch having low velocity and being lightweight. So my second question was what is spike? So spike is a set of activities that involve the extreme programming for research, design, investigation, creating POC's etc. Now we can frame your answer like this. And now moving on to the next question we have what is scrum or scrums? And here is the answer. It is a terminology used for the scaled agile technologies which is required to control and collaborate with multiple scrum teams. It is best used in situations where teams are collaborating on complex assignments. It can also include like it is also used to ensure that the required transparency, collaboration, adaption and adoption are established and to ensure that the products are deployed and delivered on a particular time. Now moving on the next question is what is user story mapping? It is now again a very important question and it's common too and how you will frame your answer is as follows. User story mapping represents and arranges the user stories that help with understanding the system functionalities system backlog planning releases and providing value to the customers. They arrange basically the user stories based on their priority on the horizontal axis and on the vertical axis they're represented based on the increasing level of sophistication. Now moving on we have what happens in the sprint retrospective and here is the answer. The sprint retrospective takes place after the sprint review. It is basically a phase. So during this meeting, past mistakes, the potential issues and new methods to handle them are discussed. This data is incorporated into the planning of a new sprint. Now moving on is what is empirical process control in scrum. And here you go. So empiricism refers to the work that based on facts, experiences, evidences, observations, and experimentation. It is established and followed in scrum to ensure the project progress and interpretation is based on facts of observations. It relies on transparency, observation and adaption. So the mindset of the team and the shift in thought process and the culture are essential to achieve the agility required by the organization. Now moving on we have what are the some drawbacks of using scrum. You can also put like what are the disadvantages of using scrum. So we'll move on and see scrum requires individuals with experience. A team needs to be collaborative and committed to the ensuring results on time does need to be very well defined. It works better for the smaller projects and is difficult to scale to larger more complex projects. So now moving on we have the next question is what are the key skills of a scrum master? So it can also be portrayed as what are the necessary skills of a scrum master. So here you can frame your answer like the necessary skills of a scrum master are he or she needs a strong understanding of scrum and agile concepts. He should have a fine-tuned organizational skills. Should have a familiarity with the technology used by the team. Then he or she should be able to coach and teach the team to follow the scrum practices. having the ability to handle conflicts and resolve them quickly and the most important one is to be a servant leader. Now moving on to the next question we have how can discord be dealt with within the scrum team and here you go for the answer. So the issues root cause needs to be identified and addressed and this is the first and the most important step. Now moving on we have the complete ownership needs to be established. Try to diffuse the disagreement. Emphasize on focus areas that complement the project. A common understanding needs to be established to guide the team basically. So performing continuous monitoring and providing the complete visibility is also very necessary. So now moving on we have the next question is what is a user story? So again a very important but a simple question and here how you can frame your answer. So your user story is an agile software development or a project management tool that provides the teams with simple natural language explanations of one or more project features written from the end users perspective. So the user story doesn't go into detail but only mentions how certain types of work will bring value to the end user. So they also form the building block of agile frameworks like epics and other initiatives. They even ensure that the team works towards the goals of the organization. The requirements to make a user story a reality are added later after the discussions with the team. So they are recorded on posted notes, index cards or the project management software itself. So now moving on to the next question is how are user stories, Apex and the task different. So they are basically asking what is the difference among these three user stories, Apex and task and here how you can frame your answer. So user stories so they provide the team with simple explanations of the business requirements required from the end users perspective. And about apex it is a collection of the related user stories. They are usually large and complex. And what about task? So task are used to break down the user stories further. So they are the smallest unit in scrum that is used to track work. A person or a team of two people usually basically work on a single task. Now moving on we have the next question is what is a sprint? And here you go for the answer. So sprint is a terminology used in scrum used to describe a time boxed iteration. So during a sprint a specific module of the product is created. The duration of a sprint can vary between a week or a two. Now moving on to the next question is what is velocity? It is not that speed velocity. It is basically the velocity or terminology used in scrum. So here you go for the answer. So the velocity is a metric used to measure the amount of work completed by a team during a sprint. It refers to the number of user stories completed in a sprint. And here you basically can see the graph and you have a basic idea of the velocity. Now moving on to the next question is what are the responsibilities of a product owner. And here you go. The product owner basically defines the vision of the project. It anticipates the needs of the customer and creates appropriate user stories. He or she even evaluates the project progress and it also asks other product related questions. Basically they can answer them. So you can frame your answer like this. Then moving on we have what is burnup and a burndown chart. This is again can be a difference on the definition of a burnup and a burndown chart. So let's see. A burnup chart is a tool that's used to track the amount of work that's been completed and to represent the total amount of work that needs to be done for a sprint or a project. And a burndown chart represents how fast working through user stories is. It shows the total effort against the amount of work for each iteration. So now moving on we have how is estimation done in a scrum project. So let's see the estimation of the user stories is done based on their difficulty. So particular scale is used to access the difficulty of the user stories. Some type of scales are uh you can even say this that you have a numeric sizing that is from 1 to 10. We have even the t-shirt sizes we all see in the balls that is from SML XL XL and and so on. The Fibonacci series 1 2 3 5 8 and so on. The dog breeds the grain examples and a lot more. Now moving on the next question is what are some the risk in scrum? So how are they handled? So let's see the answer. There are some type of risk in scrum as well. So the first one is a budget. The risk of exceeding budgets. The people basically the people the team the team members need to be appropriate skill and capability. Sprint this is basically the duration and the deliverables exceeding the duration addition of the scope of work. Then coming to the product related issues that is a user stories in epics. Having the illdefined user stories and epics can also be a problem. Then knowledge and capability having the appropriate resources is very necessary for a scrum. So managing risk involves identifying accessing and analyzing the risk and monitoring them and continuously managing them. They are done on a continual basis right from the starting of the project until the completion. So it is very necessary to understand the impact of the risk is based on the proximity of the actual occurrence of the risk. So now moving on to the next question we have how does a scrum master track the sprint process and here is answer. So they can track the sprint progress by daily scrum meetings, the scrum retrospectives, sprint planning, escape defects, defect density, the spring burndown and team velocity. And then moving on to the next question is how to deal with the score crib. So the score crib refers to the change that's uncontrolled and added without checking its impact on scope, time, cost, etc. To handle it, here's what needs to be done. So you can basically say close monitoring of work done on a day-to-day basis is necessary. Understanding and communicating the vision to the team and ensuring they're aligned. Then capturing reviewing the project requirements regularly to emphasize to the team and customer about the requirements signed off. Then ensuring that any changes introduced go through change control and are implemented based on the approval for the change request. Then avoid goldplating. Then moving on to the next question we have. What are MVP and MMP? Now here is the answer. MVP stands for minimum viable product. It is a lean startup concept that stresses the impact of learning while performing the product development. This allows one to test and understand the idea by getting exposed to the initial version for target customers and users. To accomplish this, one has to collect all the relevant data and learn from the collected data. The thought behind MVP is to produce the product to provide access to the users and to observe how the product is used, perceived and understood. Coming to MMP, it stands for minimal marketable product. It refers to the description of the product which will have a minimal number of features that addresses the requirement of the users. So now moving on to the next question. What does DOD mean? So here is the answer. Do stands for definition of done. It refers to the collection of the deliverables. You can basically make it out from the definition itself which includes the written codes, comments on coding, unit test, integration, testing, design documents, release notes and etc. So this adds verifiable and demonstrable values to project development. The is very helpful to scrum while defining the deliverables to achieve the objective of the products. It helps with defining the steps required to deliver the iteration, the usage of the appropriate tools like burndown to make the process more effective and so on. Now moving to the next question is how can a scrum master be a servant leader and again a very important and a logical question. We will answer the question. The term servant leader mainly focuses on the service orientation which a leader should demonstrate. So the scrum master needs to be a facilitator, a guide, a mentor etc. So this helps a team having increased involvement, empowerment and etc. The next question we have how can you coordinate between the multiple teams and here is how you can frame your answer. So one of the most common approaches for this is the scrum or scrums SOS meeting where members representing each scrum team discuss the progress performance issues risk etc altogether. So the frequency of these meetings must be predefined. Generally scrum masters would represent a particular scrum team besides having the chief scrum master who is basically responsible for coordination and collaboration among all the scrums who facilitates this meetings. So now moving on to the next question we have how would you handle conflict within the team. So here is the answer. So giving individual coaching to the team members is again very important one of the effective strategies to resolve a problem. So it is imperative for a scrum master to maintain the positive relationships with the team members and provide guidance when they face challenges. So for a scrum master paying attention to the source of the problem and listening and acting accordingly would go a long way. Any disagreements should be shared with other team members in a manner that would be open or to suggestions for resolving the issue. So you can even say about the following steps help in handling the conflicts within the team. Step one should be sim settings and two should be gathering information. Step three should be brainstorming to find a solution. Then final step would be solution conferring. This is how you can handle the conflict within a team. So now moving on we have how would you deal with a difficult stakeholder. The four strategies by which we can deal with difficult stakeholders are listening to them very carefully. Number two is estimating their motivation. Number three is meeting them one after the other and then the last one is watch the stakeholders closely by identifying them and this can actually give you ideas about the stakeholder. Now moving on to the next question is what are the three pillars of scrum? Again a very important thing to understand. The three pillars of scrum are summarized as it is adaption, transparency and inspection. So adaption the method being process must be changed if an inspector determines that one or more aspects of a process are outside of the permitted limits. Coming to transparency, it mandates that those elements be specified by a consistent standard in order for viewers to understand what they are viewing. Then again coming to inspection, the scrum users must check scrum artifacts and progress towards a sprint goal on a regular basis to discover unwanted deviations. Now moving on, we have the next question as explain the user story structure with an example. So this is basically a very logical question and it is very common one too. So here is a basic structure of the story you can see as a role of the user then I want to achieve a goal or perform a task so that I may achieve some goal or value. For example, the user story of a person's online course purchase can be as a customer I want to purchase educational courses online from the edtech website so that I can do not have to visit a training center and here's basically how you can write it. Now moving on we have the next question is how can you assure that the user stories meet the requirements and here you go. So a good user narrative includes both a description and acceptance criteria. It should be completed in a sprint with the fewest possible dependencies. The team should be able to develop and test while still delivering estimations with the sprints contrast. So in short good user stories adher to the invest concept. You can see basically what is it mean and you can even include this in your explanation. Now moving on to the next question is what are the five steps of the risk management? The five steps of risk management are risk identification, risk analysis, ranking the risk and then treating the risk and then finally risk review. So risk identification to identify the risk that your company is exposed to in its current operating environment. And what do you mean by risk analysis? So once a risk has been identified, it must be investigated. So that is all about analysis. Then again coming to ranking the risk. So risk must be ranked and prioritized. All risk can't be same right. So you need to prioritize which risk to treat first. Then comes the process treating the risk as much as possible. All risk should be avoided or reduced by contacting the experts in the field in question. Then coming to the final stage that is risk review to ensure that it has been entirely eradicated the risk evaluation is done. Now moving on to the next question we have. What do you mean by the time boxing in scrum? When can a sprint be cancelled and by whom? So here you go. So time boxing is a practice of devoting a set amount of time to a single activity. A time box is a unit of time measurement. A time box must not exceed 15 minutes in length. So when can a sprint be cancelled and by whom? So a sprint can be cancelled before the sprint time box limit ends. Only a product owner can cancel the sprint. So now moving on we have what do you understand about the scope creep and how can scope creep be managed. To manage the scope creep we need to use a change control mechanism to keep it under control. This includes the following. Maintaining a baseline scope and keeping the track of the project's progress. to evaluate the actual work performance metrics to the baseline scope that is how different is the current project from the original plan and we need to perform the variance analysis. Then identifying the severity and the source of the observed alterations. Then selecting whether to take the preventive or the corrective action in response to the request regarding changes. Then finally to recommend the actions and manage all the change requires by using the perform integrated change control method whether preventive or corrective. Now moving on we have the next question as when should a scrum master not act as a facilitator? Then again a very important and interesting question. It is like a workshop facilitator must be objective when it comes to the topics being discussed and should avoid contributing facts or opinions to the conversation. Even through a scrum master's job is to assist the team in achieving the best possible results. Workshop facilation can be challenging at times. So now moving on to the next question we have. How do you make the different stakeholders attend daily scrum meetings? So the coordination of the business people and the developers defines the success of a project. So the scrum master should conduct the daily stand-up meetings and encourage all stakeholders to be a part of the call by explaining the impact it will have on the project. The motive of the daily scrum is to know whether or not they will reach the sprint goal. So the next question comes what is the structure of a good story? And here you go with the answer. So the structure of a good story is as follows. Who are we building it for and what are the users? Secondly, what are we building and what is the intention of building? So again comes why are we building it and what value does it bring for the user. So well formed stories will meet the criteria of build vix invest acronym that is again invest independent, negotiable, valuable, estimable, small and testable. And now moving on to the next question is what is the role of a scrum master in a sprint retrospective? And here you go. The scrum master in sprint retrospective inspects the progress of the previous improvements. So with the help of team discussion, new improvements are also inspected and adapted. Scrum master plays the role of a facilitator for the team. Now moving on to the next question. How can scrum masters ensure timely delivery of action? items. So the regular scrum retrospective ensures the timely delivery of action items. An effective retrospective makes sure that the team has identified the action items. Some organizations use a retrospective tracker to monitor the action items. Here are the targeted categories like the priority, ownership, status, description, identified on and type. So working on the action items gives the team a boost that they are moving towards improvement and enhances the sense of ownership. Now moving on we have what do you exactly mean by sprint and scrum? So sprint is at the heart of scrum. An incremental product is released every week or every month. So after the previous sprint gets completed a new sprint begins. It breaks down large projects into smaller more manageable chunks. Daily scrum, sprint planning, sprint review and everything are a part of sprint. Now moving on to the next we have what does the concept of confidence vote mean in scrum? Why is it vital? So the confidence vote is held at the program increment planning session following the risk analysis. It is when all the team members assemble, voice their opinions and vote with their fingers on their confidence level in completing the PI targets. A vote of confidence can help create an environment where people feel comfortable sharing and expressing their ideas. So it boosts team moral because members should feel that their opinions are valued. Now moving on to the next question is is daily meeting suggested for all teams irrespective of their size or experience level. Explain. So here is the answer. During the daily meeting, a team can evaluate its progress sticking to the sprint goal or not to ensure that everyone is on the same page. All agile teams should meet frequently. So there are various ways they can conduct the meeting small and experienced, small and inexperienced, large and distributed teams. So you can frame your answer like this. Then moving on to the next question we have, can scrum team members participate in the product development process as well? Uh if it is so then please explain how and here is the answer. It is very advantageous to involve the scrum team in the discovery phase stage of the product development life cycle. The agile teams collaborate with the stakeholders early in the development cycle to ensure that the both the parties are on the same page and you can basically see the points over here and then basically frame your answer like this. Now moving on in Scrum, what do you mean by user stories and what benefits come from using them? So user story is an informal generic description of a software feature written from the end users perspective. Putting people first is a critical element of an agile software development and a user story accomplishes this by putting users at the center of the discussion. The there are some following the some benefits of using user story. So the primary benefit of user story is the user centric definition. The syntax of the user story ensures that the user's desired goal, benefit or the value gets captured. Then again because the acceptance criteria gets included in the story, the scrum team will benefit from them. So a user story can change at any time during the project's execution. So now moving on to the second last question we have is name some other agile frameworks. So there are other frameworks besides scrum such as scanban testdriven development and feature-driven development. Mention frameworks you have followed and provide the scenarios how you have used it. So now moving on to the next one is when we should use waterfall over scrum and is again very important question. So we should use waterfall if the requirements are very simple, predictable, fully defined and understood and will not change in the meantime. So you can basically all the interview questions that are very important. There can be millions of questions on scrum master but I have provided this top 50. So that's a wrap on a full course. If you have any doubts or questions you can ask them in the comment section below. Our team of experts will reply you as soon as possible. Thank you and keep learning with simply learn. Staying ahead in your career requires continuous learning and upskilling. Whether you're a student aiming to learn today's top skills or a working professional looking to advance your career, we've got you covered. Explore our impressive catalog of certification programs in cuttingedge domains, including data science, cloud computing, cyber security, AI, machine learning, or digital marketing. Designed in collaboration with leading universities and top corporations and delivered by industry experts. Choose any of our programs and set yourself on the path to career success. Click the link in the description to know more. Hi there. If you like this video, subscribe to the SimplyLearn YouTube channel and click here to watch similar videos. To nerd up and get certified, click here.