This UNOFFICIAL course focuses on teaching Scrum and the role of the Scrum Master, with the goal of preparing participants for the PSM I certification. It also demonstrates how to apply the Scrum framework in practice through a fictional scenario of a team building a website for a fictional client. The course covers introducing Scrum to the team, setting up Scrum events, and running the first sprints. Additionally, there are practice exams based on PSM I assessment questions provided. I encourage enjoyable learning throughout the course. This course is not affiliated or endorsed by Scrum org but it will help to prepare you for their assessment.

This lecture introduces a role-playing scenario where you, as a newly appointed Scrum Master with your PSM I certification. You are tasked with leading a team to deliver a website for a new client, Bike Group, within four months. The company is facing resource constraints and the client's requirements are unclear. To address these challenges, you've been instructed to manage the project using agile principles and the Scrum framework.

The team you're leading consists of a mix of interns and experienced professionals, each with their own areas of expertise. Quinn is a talented back-end developer, Philip is a skilled front-end developer, Josh is a digital marketing expert, Amy is a promising designer, and Becky, the product owner, brings experience in the bike industry and e-commerce.

Given the time constraints and the team's lack of knowledge about Scrum, it's crucial for you to quickly grasp the Scrum framework and apply it effectively to ensure the successful delivery of the project

This lecture introduces a new section on artificial intelligence (AI) to the course. The section will explore how organizations are currently leveraging AI and offer predictions for future applications. The goal is to provide insights into how AI can be applied to your organization and your role as a certified Scrum Master, as well as how it can be used to improve products and automate operations. Given the significant impact of AI, this topic is presented as a fascinating and essential addition to the course.

This lecture provides a concise overview of Scrum, a framework for iterative and incremental product development. Scrum emphasizes flexibility and adaptability by focusing on short development cycles called sprints. Each sprint involves planning, development, and review, allowing for continuous feedback and adjustments. Scrum promotes teamwork by forming cross-functional teams with clear roles and responsibilities. The product owner ensures the product's value, the Scrum master facilitates the process, and the developers execute the work. Regular meetings, such as the Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective, foster collaboration and continuous improvement. By following these principles, Scrum teams can effectively deliver valuable products while adapting to changing requirements and challenges.

I answer more Scrum Questions and help students via my Facebook Group and YouTube Playlist (see the link in the resources)

This lecture dives into the purpose of the Scrum Guide, created by the pioneers of Scrum, Ken Schwaber and Jeff Sutherland. It emphasizes the importance of understanding the entire framework, as altering or omitting elements can hinder Scrum's effectiveness. While originally designed for software development, Scrum's applicability extends to various product development endeavors, with "developers" referring to any specialists involved in the creation process. The lecture reinforces the Scrum Guide as the primary resource for applying Scrum and preparing for the PSM I certification exam.

This lecture clarifies Scrum as a lightweight framework, not a rigid method or process, designed to help teams and organizations tackle complex problems through adaptable solutions. It highlights the core elements of Scrum, including the product owner's prioritization of the backlog, the team's iterative development, and the continuous inspection and adaptation of results. This simplified overview provides a foundational understanding of Scrum, while future lessons will delve deeper into specific roles and principles.

This information is relevant to the PSM I certification exam, as understanding the Scrum framework and its key components is crucial for successful certification.

This lecture emphasizes the importance of the Scrum Glossary as an essential resource for both understanding Scrum and preparing for the PSM I certification exam. The glossary provides definitions for key Scrum terms, including "burn up chart," "burn down chart," and "definition of done." Understanding these terms is crucial for successful certification, as the exam might draw questions directly from the glossary. The lecture highlights the glossary's value alongside the Scrum Guide as core resources for Scrum mastery.

This lecture provides an overview of the course structure, highlighting the two main sections: theory and practical demonstrations. It emphasizes the importance of combining theoretical knowledge with practical examples for effective learning. The course is organized to cover the fundamentals of Scrum in the order of sprint events, with more advanced topics and in-depth discussions of the Scrum Master role introduced later. This structure allows learners to progress at their own pace and focus on specific areas of interest, such as the Scrum Master role.

This lecture introduces the concept of reflecting on past project experiences to identify areas for improvement. The instructor suggests choosing a project where things didn't go perfectly and writing down five bullet points of problems and five bullet points of things that didn't go well. This will serve as a foundation for exploring the Scrum framework and how it could have potentially addressed these challenges.

This section discusses the Scrum org Professional Scrum Master certification, PSM I, which is the first step in a series of courses offered by Scrum org. The course also mentions the Product Owner certification, PSPO I, which has similar questions and is recommended to be attempted alongside PSM I. The PSM I certification assessment consists of multiple-choice questions, some of which have multiple correct answers. The passing score is 85%, and candidates have 60 minutes to answer 80 questions. Preparation strategies include watching the course, attempting mock exam questions, studying required reading material, and practicing with free Scrum questions available online. The course encourages candidates to visit the Scrum org website for more information and wishes them good luck.

Scrum org offers valuable and well-organized resources for free on its website, covering various aspects of Scrum. These resources cater to individuals interested in becoming Scrum Masters, Product Owners, leaders, or software developers. The website provides blogs, videos, and other formats to explore topics such as the agile manifesto, empiricism, scrum events, and the scrum goal. For instance, there are blog posts discussing the pillars of empiricism and videos explaining concepts like empiricism using relatable examples. Visitors can also find resources on developing people, managing products with agility, and more. Engaging with these resources not only enhances understanding of Scrum but also aids in applying it effectively in practice.

Scrum org offers a dedicated section for videos, providing a valuable resource for individuals who prefer learning through this format. Accessible from the top right corner of the website, this section contains numerous videos covering various aspects of Scrum. Exploring different resources, including videos, is recommended not only for preparing for the PSM I certification but also for staying updated on Scrum practices and theory changes. Continuously engaging with such resources helps in further solidifying one's understanding of Scrum.

As a Scrum Master, your primary responsibility is to establish Scrum practices defined in the Scrum Guide, helping the team understand theory and practice. You're accountable for the team's effectiveness by enabling improvements within the Scrum framework, essentially becoming the Scrum champion. Your role involves removing impediments and blockers to progress, serving as a true leader. While previously described as a servant leader, the Scrum Master serves the team, Product Owner, and organization, with a focus on embedding Scrum, enhancing team effectiveness, and providing leadership support.

This lecture introduces the role of the Product Owner in Scrum, a framework for managing complex projects. The Product Owner is responsible for maximizing the value of the product by prioritizing work tasks, defining the product goal, and ensuring the product backlog is transparent and understood. They are accountable for their decisions and work with stakeholders to understand customer needs. The organization must respect and trust the Product Owner's judgment, as their decisions contribute to the overall success of the product.

This lecture introduces the role of Developers in Scrum. Developers are cross-functional team members who work collaboratively to create increments of the product within each sprint. They are empowered and self-managed, responsible for planning, executing, and ensuring quality throughout the sprint. Developers are accountable for creating a sprint plan, adhering to the definition of done, adapting their plan daily, and holding each other accountable. The sprint backlog is the list of tasks for the sprint, the definition of done sets the criteria for completing tasks, and the sprint goal is the overall objective of the sprint. Developers should hold each other accountable and address issues as a team. Scrum teams typically consist of 3-9 members.

This lecture emphasizes the structure and size of a Scrum team, which consists of a Scrum Master, a Product Owner, and Developers. While the Scrum Master and Product Owner can also participate in development, the team should remain small and cohesive, ideally consisting of no more than 10 members to enhance communication and productivity. The importance of maintaining a nimble team is highlighted, as larger teams may hinder effectiveness. The Scrum Guide advocates for these principles to ensure the team can focus on achieving their product goal efficiently.

This lecture highlights the critical role of the Product Owner within the Scrum framework, emphasizing their responsibility to ensure that the team's work is valuable and aligns with the overall product vision and goals. The Product Owner plays a vital role in delivering a product that meets customer requirements and benefits the business. Participants are encouraged to reflect on past projects where roles may have been misaligned, particularly considering whether a Product Owner was present. By examining these roles retrospectively, individuals can better understand the importance of having a clear vision and effective communication among team members. This reflection can inform future projects, reinforcing the need for defined roles within Scrum to enhance outcomes.

Becky, the Product Owner, has been tasked by the bike club to create a website shop targeting young professional women aged 20 to 35, with a modern, feminine, and friendly aesthetic. The website needs to promote specific bike models based on supply and demand changes and have typical online shop functionalities such as search, sort, and filter options. Additionally, the site should include pages for articles, news, and search engine optimization. However, the bike club's requirements are somewhat vague, leaving room for interpretation. Becky anticipates that requirements may change during development, a concern stemming from past experiences with lengthy projects that didn't meet customer expectations. The goal is to use Scrum to iteratively develop the website, addressing uncertainties and ensuring customer satisfaction.

This lecture focuses on the significance of determining sprint length in Scrum, which is essential for establishing a consistent workflow. Sprints are fixed-length events, ideally lasting one month or less, and they should begin immediately after the conclusion of the previous sprint. The speaker recommends two-week sprints as a balanced approach, allowing for frequent inspection and adaptation without hindering progress. Each sprint encompasses several key events, including sprint planning, daily scrums, sprint reviews, and sprint retrospectives, all aimed at facilitating transparency and enabling teams to inspect and adapt their work effectively. These events help minimize the need for additional meetings while ensuring that communication remains a priority. The lecture concludes with a practical exercise of scheduling these events in Microsoft Outlook, reinforcing the structure of Scrum and its processes.

The focus now is on scheduling sprint events, ensuring they're in everyone's calendars as placeholders, even though scheduling around other commitments may be challenging. The first step is to plan a kickoff meeting to introduce the team, discuss the project, and explain Scrum principles. This meeting includes introductions, project overview, and Scrum framework explanation. Following this, the team will engage in a requirements gathering session to initiate the backlog. This session involves brainstorming and categorizing requirements, prioritizing them, and potentially considering risks and dependencies. The aim is to develop the product backlog for sprint planning. The meeting agendas include introductions, discussing known requirements, brainstorming, categorizing and prioritizing requirements, and setting the stage for sprint planning. While agendas may vary, the primary goal remains to initiate the backlog and prepare for sprint planning. Detailed agendas and stakeholder management discussions are covered in the practical section of the course.

In this section, you emphasize the importance of determining the sprint length in establishing the Scrum framework, highlighting that sprints cannot exceed one month. You propose bi-weekly sprints as a balanced choice to enable regular feedback while minimizing disruptions and stress the significance of consistency in the sprint start day. Key events include scheduling a three-hour sprint planning meeting on Tuesday at 10 AM, ensuring project names are included in the titles for clarity, and inviting relevant stakeholders to assist in planning. A structured agenda for the sprint planning meeting should include discussions on the sprint goal, product backlog review, and team capacity assessment to determine the sprint backlog. Additionally, you recommend setting the sprint planning as a recurring meeting every two weeks with a specified end date based on the project roadmap, and highlight the necessity of daily scrums to maintain communication and address impediments effectively.

The daily Scrum should be scheduled for 15 minutes at 9 AM, and it's essential for you, as the Scrum Master, to ensure that it stays within this time limit. The daily meeting should include the Scrum team, and it's common to hold it in a standing format to encourage brevity in updates. Participants should briefly share what they accomplished yesterday, their plans for today, and any blockers they're facing, based on guidance from the Scrum Guide. Following the daily Scrums, you need to schedule the sprint review and sprint retrospective, which will occur on the Monday after the sprint wraps up. It's crucial to ensure that all meetings are set for weekdays only, avoiding weekends to maintain professionalism. Before sending invites, make all necessary adjustments in your calendar to avoid multiple notifications and spam for recipients. Once everything looks good, forward the finalized invites to the team to maintain clear and efficient communication.

To conclude our sprint process, we will hold the Sprint retrospective, which provides a valuable opportunity for the team to reflect on the sprint's performance in a relaxed and informal setting. It's best not to schedule this meeting immediately after the Sprint review, as participants may feel fatigued. Instead, we'll allow for a break before starting the retrospective, keeping it concise at one hour. Although the ideal duration for a monthly sprint retrospective is up to three hours, this shorter format will maintain engagement.

We will invite the Scrum team and set a specific location for the meeting, ensuring that an agenda is in place, referencing the Scrum Guide for guidance. It may also be beneficial to utilize a free online tool for anonymous feedback during the retrospective, which I can assist with setting up in advance. This meeting will repeat every two weeks on Mondays, rounding out our sprint events: Sprint planning on Tuesdays, daily scrums every weekday, a Sprint review rehearsal before the official review, and the Sprint review itself. This comprehensive schedule ensures we cover all necessary activities to reflect on our progress and enhance our team's performance moving forward.

Sprints are the core of Scrum, each lasting one month or less, providing consistency and predictability. They facilitate inspection and adaptation through sprint events: sprint review, sprint retrospective, and sprint planning. Sprints start immediately after the conclusion of the previous one, ensuring continuous progress towards the product goal. Sprint planning sets the sprint goal, determining what the team aims to achieve in the sprint. Shorter sprints generate more learning cycles and limit risks, but excessively short sprints may hinder productivity. Burn-up and burn-down charts, although not part of the Scrum framework, aid in tracking progress and forecasting. Only the product owner has the authority to cancel a sprint if the sprint goal becomes obsolete. In such cases, a review, retrospective, and immediate sprint planning are essential for adaptation and continuous progress.

In summary, you've learned about the roles and events within Scrum and have set up consistent scheduling for these events. Now, it's time to delve into Scrum artifacts. There are three main artifacts: the product backlog, the sprint backlog, and the increment. Take a moment to jot down what you already know about these artifacts, as we'll explore them further in upcoming lectures.

This lecture focuses on the product backlog, which is an emergent, ordered list that outlines everything required to build and improve a product, serving as the single source of work for the Scrum team. It emphasizes the importance of having a singular source of requirements, eliminating confusion from conflicting documents. The product backlog is continually refined and prioritized, allowing the team to adapt as needed, with the product owner accountable for managing it effectively. This includes articulating the product goal, defining backlog items, and ensuring transparency. The product goal, such as creating an enticing, user-friendly website shop to convert visitors into customers, guides the team's planning efforts and highlights that Scrum can encompass more than just software development. Next, we will explore product backlog refinement.

This lecture discusses the product backlog as an emergent list of tasks essential for building a product, starting with high-level items like Epics, which are large bodies of work that can be broken down into smaller tasks. For instance, in creating a website, an Epic could be "design the website," while others might involve setting up technical architecture or creating necessary images. As these high-level tasks require more detail, ongoing product backlog refinement becomes crucial. This involves adding descriptions, ordering items, and estimating time to complete tasks. While the Scrum Guide does not specify a time commitment for backlog refinement, it historically recommended that this process should consume no more than 10% of the Scrum team's capacity, underscoring its importance despite being considered outside of formal Scrum events. It's vital for developers to break down backlog items into manageable tasks they can complete within a single sprint, allowing for better estimation and planning, as they are responsible for assessing the time and effort required. Overall, the product backlog is maintained throughout the product's lifecycle, ensuring it remains relevant even post-launch, as maintenance and improvements will still be necessary. Next, we will put this theory into practice with product backlog refinement

In summary, before delving into sprint planning, it's crucial to establish the backlog, which requires gathering requirements. The initial information from the customer outlines the objective of creating a user-friendly website that converts visitors into customers. To monitor this objective, key results are defined, such as the percentage of visitors converting into customers. Other objectives include ensuring the site's safety, reducing bounce rates, encouraging repeat visits, and optimizing user-friendliness. The target customer base and desired functionality, akin to leading web shops like Amazon, further guide the requirements. A brainstorming session involving the entire Scrum team, customers, stakeholders, and relevant experts is scheduled to flesh out these requirements using the MoSCoW categorization method, which prioritizes must-haves, should-haves, could-haves, and won't-haves.

Find my reference to OKR definitions here:

https://www.workfront.com/strategic-planning/goals/okr

https://www.workfront.com/strategic-planning/goals/okr/okr-examples

This lecture focuses on the importance of identifying and understanding stakeholders when developing a website, emphasizing the need to consider their perspectives to gather relevant requirements. Stakeholders can be internal, such as employees and company owners, or external, including customers and suppliers. The discussion highlights the difference between website users and customers, underscoring the significance of user-focused design. It introduces Agile terminology, such as initiatives, epics, and user stories, illustrating how these concepts can help articulate requirements clearly. For example, user stories are crafted from the end user's perspective, ensuring that the development process remains aligned with their needs. The lecture stresses the necessity of continuously engaging stakeholders throughout the project, ensuring that all relevant parties are identified and involved, ultimately enhancing the website's effectiveness. Additionally, concepts related to a PSM may be relevant in guiding the team through stakeholder collaboration and Agile project management methodologies.

This overview emphasizes the effective management of requirements and their translation into a backlog for software projects, particularly in the context of Scrum Master principles, using tools like Google Sheets or Excel. Initially, these documents capture key requirements—such as the need for the website to be enticing, user-friendly, and effective at converting visitors into customers—before being transferred to a project management tool like Trello or JIRA, ensuring no duplication occurs. Requirements are categorized into epics, such as website shop features, news areas, and performance/security aspects, with user stories illustrating needs from different perspectives, like those of website visitors and customer managers. Prioritization into Must Haves, Should Haves, Could Haves, and Won’t Haves guides the focus on creating a Minimum Viable Product (MVP) through iterative development, a core tenet of Scrum. This process distinguishes between functional requirements (direct features) and non-functional requirements (usability factors) while utilizing empirical evidence and user feedback for ongoing adaptation. The goal is to transition seamlessly from the initial requirements sheet to the backlog, using it as a reference during sprint planning to ensure an effective and user-focused software development process.

Trello is a colorful and user-friendly work management tool that visually organizes tasks as tickets, allowing teams to move them through various stages from backlog to completion. As part of the Atlassian software suite, Trello serves as a simplified version of JIRA, which is more powerful and capable of generating detailed reports. In this session, I will demonstrate how to create a product backlog and manage Scrum fundamentals using Trello, specifically for a bike club website project. After signing up for a free Trello account, I’ll create a new workspace and invite team members using their corporate email addresses. We'll set up our board with essential columns such as Product Backlog, Sprint Backlog, To Do, In Progress, and Done. Each requirement will be added as a card, complete with user stories, definitions of done, and color-coded labels for epics to enhance clarity and organization. This approach allows for quick adjustments to requirements and ensures transparency, as team members can track progress through the checklist feature. By refining and decomposing tasks throughout the sprint events, teams can adaptively build the product without needing to finalize every detail upfront. Additionally, as a certified Scrum Master, I emphasize the importance of iterative development and continual inspection and adaptation to meet project goals effectively.

In our first backlog refinement session, we’ll focus on preparing for the initial sprint by examining a variety of tickets, particularly prioritizing those that will drive our early work. Not every ticket requires immediate attention; instead, we should concentrate on high-priority items to ensure we can start the sprint effectively. It’s essential to consider dependencies, such as selecting the website's architecture and hosting platform, before diving into the build process. Design efforts should align with the company’s branding guidelines, allowing our designer, Amy, to begin sketching out the website layout. The developers will collaborate to finalize the website architecture, while Josh, our marketing expert, will assist Amy in designing promotional materials. As we identify additional tasks during this brainstorming phase, we'll refine our backlog further. One of the key tasks will be to gather the company's branding rules, ensuring they are documented and accessible for the team, which will help us maintain consistency across our design efforts. This task will involve working with the marketing department to obtain existing guidelines or creating new ones if necessary. We’ll also engage with senior management for final approval. In terms of user stories, we'll emphasize user perspectives, focusing on the need for a stable and secure website that users can navigate easily. Each task will include a "definition of done," which outlines necessary steps for completion, such as producing an architecture document, selecting technology stacks, and ensuring user testing is incorporated into the development process. User-friendly design is crucial, necessitating the creation of a user group to gather feedback and validate that our designs meet user expectations. This collaborative approach, involving contributions from the entire scrum team, will help us refine our definitions of done over time, improving our overall ticket quality and ensuring we align with the standards of our organization as we progress.

The decision matrix is a powerful tool for making informed choices by evaluating and prioritizing alternatives based on predefined criteria, making it particularly useful for complex decisions involving multiple factors. To use a decision matrix, first identify the criteria relevant to your decision, such as cost, user-friendliness, features, and customer support. Next, assign weights to each criterion based on its importance, then list the alternatives you’re considering. After that, score each alternative against the criteria using a numerical scale, and calculate the total scores by multiplying the scores by the assigned weights. Finally, select the alternative with the highest total score as the most favorable option. For instance, in choosing project management software, you might weigh cost at 30%, user-friendliness at 25%, features at 30%, and customer support at 15%. By engaging your team in this structured approach, you not only make a logical decision but also demonstrate your skills as a certified Scrum Master in facilitating collaborative decision-making processes.

The sprint backlog is akin to the product backlog but owned by developers, serving as a plan for them during the sprint. It's a dynamic list updated throughout the sprint, ensuring tasks have enough detail for daily scrums. Comprising the sprint goal, selected items, and delivery plan, it's crucial for achieving sprint objectives. Developers commit to the sprint goal, which is set during sprint planning, allowing flexibility in execution. The goal fosters coherence, focus, and teamwork, aiding in scope negotiation within the sprint. Only the product owner can cancel a sprint if the goal becomes obsolete. With the product backlog refined, the sprint planning session is imminent, marking the next step in the Scrum process.

This lecture discusses increments, and essential steps toward the product goal, such as adding a blog section or online ordering system in website development. Each sprint should produce an increment, with Scrum 2020 allowing for multiple increments to be presented to stakeholders before the sprint review, preventing bottlenecks. Increments must be additive and thoroughly tested for compatibility within the larger product. The "Definition of Done" formalizes quality standards, ensuring transparency among team members. Items that do not meet this definition cannot be shown at the sprint review and must return to the product backlog. Organizations may have minimum standards, including testing and branding guidelines; if not, the Scrum team must establish their own. Multiple Scrum teams working on the same product need a unified definition of done. Once developers meet this definition, an increment is ready for stakeholder presentation and potential user release, without waiting for the sprint review.

Establishing a clear "definition of done" for the increment is vital for ensuring transparency and maintaining standards in the Scrum process. It sets clear guidelines that must be met before an increment can be considered complete. The definition of done should be clear, testable, measurable, concise, and realistic. Obtaining input from relevant departments or personnel in the organization can help establish appropriate standards. The definition of done checklist typically includes testable criteria such as meeting style guides, optimizing images for the web, peer code reviews, integration testing, user testing, accessibility standards, performance testing, and adequate documentation. Non-functional requirements such as user-friendliness, security, performance, and design considerations should also be incorporated into the definition of done. Metrics and key performance indicators (KPIs) can be used to monitor and evaluate the performance of the increment against these criteria. Regular reflection and refinement of the definition of done, along with input from stakeholders and peers, can help improve the quality of increments over time.

This lecture discusses the final stages of a sprint, emphasizing the importance of verifying that the created increment—such as a "Coming Soon" page—meets the standards outlined in the definition of done. A checklist is utilized to ensure all criteria are met, including performance metrics like visitor counts and user sign-ups. The lecture also highlights the value of standardizing the definition of done for future increments and potentially creating a template for efficiency. Ultimately, while the development team ensures the increment is ready, the decision to release it to users rests with the product owner, reinforcing the importance of adherence to quality standards and strategic timing in product management.

Sprint planning is a crucial event in Scrum, initiating sprints and requiring a well-prepared product backlog. The product owner leads the discussion on important backlog items and their alignment with the product's goal. The sprint planning involves the entire Scrum team and possibly other stakeholders. Its outcome is a detailed plan for achieving the sprint goal, determined by considering why the sprint is valuable, what can be done, and how the work will be executed. The product owner proposes how to increase product value, and the team collaborates to define the sprint goal. Developers estimate the work to be done, selecting backlog items for the sprint and planning their execution. The event should not exceed eight hours for a month-long sprint and should be shorter for shorter sprints. Effective planning is essential to avoid wasting time and resources in the sprint.

This lecture summarizes the sprint planning meeting, by focusing on efficiently planning an upcoming two-week sprint with an emphasis on backlog refinement and defining a clear sprint goal. The purpose of the meeting is to prepare the backlog for the sprint by ensuring it is ready for pulling tasks, aiming for a maximum of four hours of planning. A clear sprint goal has been established: "Create the coming soon page," which includes securing hosting and technology, beginning user group formation, and planning the website architecture and wireframes. Key elements of the sprint planning include assessing the sprint's value by establishing a foundation for building the website and engaging stakeholders. Tasks for the sprint encompass architecture designs, technology decisions, and user group setup. Developers will determine how to approach and complete these tasks, utilizing techniques like planning poker to estimate task durations without falling into groupthink. The team capacity includes four developers available for ten days, and tasks will be broken down into manageable sizes. Collaboratively, the scrum team will assign responsibilities: Josh will handle user group tasks, Philip will focus on the coming soon page, and Amy will clarify her workload for wireframes. The team will actively manage capacity by listening to feedback to avoid overloading anyone, with the possibility of revisiting the sprint goal as needed. Finally, the next steps will involve finalizing and assigning tasks and scheduling daily scrums to track progress and address challenges.

This lecture discusses the importance of agile estimation in project management, specifically addressing the challenges faced by teams in meeting deadlines and managing client expectations. During a recent team meeting, it was highlighted that the deadline for a new feature was missed, leading to concerns from clients. Team members acknowledged that they encountered unexpected roadblocks and underestimated task complexities, resulting in a lack of accurate estimates. The Scrum Master proposed the agile estimation method, which focuses on relative sizing of tasks instead of fixed timeframes. This approach allows teams to assign story points based on the complexity of tasks, using the Fibonacci sequence to gauge effort relative to previous tasks. By practicing agile estimation, teams can improve their accuracy in predicting how much work can be completed in a given timeframe, leading to more predictable project outcomes. This method emphasizes delivering value rather than adhering to rigid deadlines, ultimately reducing stress and enhancing team performance. For further guidance on implementing this process effectively, refer to my video on agile estimation.

This lecture discusses the challenges of accurately estimating tasks in project management and introduces strategies such as relative estimation using story points and value points, along with the "bang for the buck" score, to improve prioritization and adaptability while emphasizing the importance of continual reassessment and experience to enhance accuracy and maintain project value.

The daily scrum is a crucial practice in Scrum, aimed at ensuring transparency and communication within the team. It's a brief 15-minute meeting held every day, where developers discuss their progress towards the sprint goal and plan their work for the day. While only developers are required to attend, it's advisable for the scrum master to join at least initially to ensure effectiveness. The format typically involves standing updates on what was done yesterday, plans for today, and any blockers. The meeting promotes communication, identifies impediments, and facilitates quick decision-making, ultimately eliminating the need for additional meetings. However, developers can still convene throughout the day for more detailed discussions and adjustments to the sprint plan as needed.

The daily scrum, a brief 15-minute event for developers to inspect progress toward the sprint goal and adapt the sprint backlog, encourages standing to keep updates concise. Josh reported that he created a targeting list, made one advert, and outlined promotional offers yesterday; today, he plans to create two more adverts and present promotional options to the marketing director, with the blocker being the director's approval for the offers. Philip finalized the text for the Coming Soon page yesterday and will discuss contact methods with the customer service team today, pending their decision. Amy designed three options for the Coming Soon page yesterday but will hold off on the contact page until after Philip's meeting, opting instead to research branding for wireframes. Quinn explored technology and hosting options yesterday and will start on the logical diagram today, with no blockers reported. Moving forward, the team will continue with their tasks and promptly address any impediments, updating the backlog as necessary.

This lecture highlights a common issue that can arise during the daily scrum, where Amy, one of the developers, identified the need to add a new task—gathering branding information—to help with wireframe design, due to a dependency on the outcome of a meeting. Since developers fully own the sprint backlog, Amy negotiated with Becky, the product owner, to include this task in the sprint. According to the Scrum guide, changes during the sprint should not endanger the sprint goal, but scope can be clarified and renegotiated. Amy prioritized the branding task, which may impact her ability to complete other tasks, such as the wireframes for the contact page. After Becky agrees that this task adds value, Amy will incorporate it into the sprint backlog while ensuring it aligns with the sprint goal. The lecture emphasizes the importance of developers managing their workload and capacity, balancing new tasks with delivering the sprint goal, and adapting when necessary while keeping the sprint goal in focus.

This lecture covers day two of the daily scrum. The team starts with updates, beginning with Amy, who reports that she negotiated with the product owner and brought the task of gathering branding rules into the sprint. She collected some branding rules and scheduled meetings with the marketing team and senior managers. Today, she plans to either create a new branding rules document or update the existing one. Josh, who was working on creating user groups, managed to create two more adverts for split testing and secured a promotional offer. His focus today is on creating and testing the contact form for the adverts, though he identifies a potential dependency with Philip regarding the contact form options. Philip, meanwhile, has made progress with the customer service team on contact methods and will create templates for the new website, though he notes a blocker, as he cannot finish his task until Amy provides the branding rules and wireframes. Lastly, Quinn has completed a logical diagram and explored technology options for the website and will present these to the CTO for a final decision. The scrum ends with all updates shared and tasks aligned.

On day three of the daily scrum, Amy updated the team that she had gathered and updated the branding rules document, but hasn't received feedback from senior managers yet, which poses a problem. She's focusing on getting that feedback today but plans to move on to creating wireframes for the contact page if needed, as the team relies on her progress. Feeling over capacity due to the extra ticket she brought into the sprint, Amy's dependencies are affecting others, such as Josh, who managed to get the advertising budget approved but is also stalled on his contact form due to the pending branding rules. He decided to help Amy to move things along. The team informed the scrum master that progress toward the sprint goal was slowing, prompting a suggestion to seek senior manager feedback via email instead of waiting for a meeting. Meanwhile, Josh tested his contact form but can't complete or user-test it until the branding rules are finalized. Philip made significant progress, creating a decision matrix, getting it approved by the CTO, and now moving on to purchasing the selected option. With no blockers, Philip is ahead, while the team adjusts priorities and tasks to support Amy and address the dependency issue, ensuring alignment with the sprint goal.

On day four of the daily scrum, the team made significant progress after getting unblocked. Amy received the necessary feedback on the branding rules, which she has now completed and moved into the "review" column on the board, seeking a team member to confirm its completion. She plans to work on user feedback for the three wireframes she created for the contact page, which will allow Philip to proceed. Josh, having applied the branding rules, finished his adverts and sign-up form and will begin split testing today to monitor the results. Meanwhile, Philip is still partially blocked, awaiting feedback from Amy on the wireframes for his contact forms, but he's continuing to assist Amy in moving things forward. Quinn has completed his architecture work and volunteered to review the branding rules, while Josh will review Quinn's architecture ticket, with Philip offering technical assistance if needed. Overall, the team is progressing well, focusing on finalizing tasks and reviews while continuing to clear dependencies as they approach the sprint goal. Day five will see further progress as reviews and user feedback are integrated into the workflow.

On day five of the sprint, the team has made notable progress. Amy’s ticket for the branding rules was confirmed as done, and Quinn's architecture ticket was also marked as completed. Any unfinished work or issues would be moved back from "review" to "in progress" for further action, but in this case, the team is making strong headway. Amy, with support from the team, has created wireframes for the contact and "coming soon" pages, completed user testing, and handed them off to Philip, the front-end developer. Philip is now working on building the contact form and front-end elements, including text and images, and plans to user-test the page with no current blockers. Meanwhile, Josh is reviewing his advert's performance and making adjustments as needed, signaling that most developers have wrapped up their tickets.

Reflecting on this sprint, the team may have initially overestimated the amount of work they could complete, a common occurrence, especially for less experienced teams or those working together for the first time (a point often discussed in the PSM I curriculum). The team demonstrated Scrum principles well by addressing impediments such as dependencies and workload imbalance through collaboration. The Scrum Master also facilitated the removal of these blockers effectively, enabling progress toward the sprint goal. Although more tasks may still emerge as the sprint wraps up, the team is on track to finalize key deliverables and prepare for the web page launch.

At the end of the sprint, it's time for the Sprint Review, a crucial event where the Scrum team presents their work to key stakeholders. The focus is on showcasing accomplishments, discussing progress towards the sprint goal, and gathering feedback. Key stakeholders like customers, bosses, or department heads are invited. The Product Owner plays a vital role, ensuring decisions maximize product value. The meeting should be collaborative rather than a lengthy presentation. It's a working session for feedback and adjustments. As a Scrum Master, aim to keep it within four hours for a month-long sprint, adjusting for shorter sprints.

The Sprint review is crucial for presenting progress to influential stakeholders, making the Stakeholder Interest-Influence Matrix a valuable tool for managing them. The matrix helps categorize stakeholders based on their interest and influence, guiding how to communicate effectively. For those with low interest and influence, general updates like newsletters suffice. Those with high interest but low influence may need progress reports or Sprint review slides. High influence but low interest stakeholders, like CEOs, need status reports outlining progress, risks, and milestones. The most critical group—those with high influence and high interest, such as program managers and key users—should be invited to the Sprint review, as their feedback and direction are essential. Overall, the Sprint review is a key opportunity to showcase progress, gather feedback, and ensure alignment with influential stakeholders.

The Sprint Review, as outlined in the Scrum Guide, serves to inspect the outcomes of the sprint and plan for future adaptations. It emphasizes the collaborative nature of the review, where the entire Scrum team presents their work to key stakeholders, fostering transparency about what was accomplished, what wasn’t, and why. This meeting is an opportunity to gather feedback that informs the next sprint and should be time-boxed, ideally lasting no more than four hours for monthly sprints or two hours for bi-weekly sprints. The agenda typically begins with a restatement of the sprint goal, followed by a review of developed and unreleased features and their impact on release plans. The team should prioritize discussing key requirements and share the sprint status using tools like burndown charts, while addressing any incomplete tasks positively and constructively. Demonstrations of key features should take center stage, allowing developers to showcase their work to stakeholders, followed by discussions and feedback. The Product Owner also plays a critical role, engaging with stakeholders about backlog items and potential market changes that may affect future sprints, as well as discussing risks and dependencies. The Scrum Master concludes the review by addressing any remaining questions and encouraging reflection on the effectiveness of the meeting during the Sprint Retrospective. Adaptability is key, allowing the team to refine their stakeholder engagement and agenda based on feedback and experience

This lecture covers the essentials of a risk register in project management, focusing on RAID: Risks, Assumptions, Issues, and Dependencies. Risks are potential negative events that could hinder product development, while Assumptions are taken when information is lacking, such as assuming no major global changes will affect bike demand, which may not hold true in light of trends like remote work. Issues arise when identified risks manifest, such as a website crash becoming a real problem needing immediate attention. Dependencies are elements that block progress due to reliance on other tasks or resources, and Scrum aims to identify and eliminate these impediments. Each risk in the register should have a unique ID, dates raised, descriptions, risk scores reflecting likelihood and impact, and a traffic light system indicating severity (red, amber, green). Risks can be categorized as high urgency or low urgency based on their development stage. Mitigation strategies include reducing, avoiding, accepting, or transferring the risk. The register should specify an owner for each risk, indicating who is responsible for monitoring it, and track its status, whether open or closed. This information is essential for discussion during the Sprint Review, ensuring that all aspects of project risks are addressed effectively.

This lecture will cover key practices for conducting effective Sprint Reviews. First, keep your presentation concise, ideally under ten slides, to respect the time of your audience. Conduct a dress rehearsal to refine your delivery and build confidence, ensuring you maximize stakeholders' time. Engage your developers in practicing their demonstrations, as this prepares them for a non-technical audience and enhances understanding of the functionalities presented. As a Scrum Master, facilitate the meeting by keeping track of time and ensuring that everyone adheres to their allotted speaking periods. Contextualize demonstrations by referencing the associated user stories, making it easier for stakeholders to connect with the presented functionalities. Use plain language, avoiding jargon, and encourage feedback from stakeholders after each demonstration. Be mindful of common mistakes, such as being unprepared, overloading content, and failing to involve all team members. Ensure that key stakeholders are present, as their input is invaluable, and never skip the Sprint Review; if conflicts arise, find an alternate time to hold the review. With these guidelines in mind, let's transition to the presentation for the bike club, where we will outline how to structure the Sprint Review effectively while showcasing the functionalities developed during the sprints.

This lecture introduces you to your first Sprint Review, a crucial opportunity to showcase your team's accomplishments to stakeholders. As the Scrum Master, your role involves inviting influential stakeholders, sending out the agenda, and facilitating the meeting to ensure it remains on schedule and appears professional. You'll begin by stating the sprint goal: to create the "Coming Soon" page for establishing a user group, gathering feedback, and planning the website's architecture and technology. The roadmap outlines phases, starting with the Coming Soon page, followed by the Contact Us page, Home page, and news articles to enhance content and SEO, culminating in developing the shop with robust functionalities. In this sprint, your team completed tasks such as creating the user group through a promotional advertisement, developing wireframes, launching the Coming Soon page, and finalizing the website architecture. Since the Coming Soon page was already released, consider embedding engaging media in your presentation. During the demonstrations, developers will showcase their contributions, with Amy discussing wireframes, Quinn covering the architecture and technology choices, and Josh presenting user group success metrics. After the demonstrations, address key risks, assumptions, issues, and dependencies, focusing on integration challenges with the stock system and customer relations. The Product Owner may share market insights to update the backlog for features like electric bike filters. Remember, the Sprint Review is a time for discussion, so take notes on feedback and action items, share them transparently, and follow up on progress in the next sprint. Finally, reflect on the meeting in the Sprint Retrospective to identify improvements for future reviews.

The Sprint Retrospective, or Sprint Retro, is the final event of the sprint aimed at enhancing quality and effectiveness. The Scrum team reviews the previous sprint, focusing on individual interactions, processes, tools, and the definition of done. It's an opportunity to discuss successes, challenges, and potential improvements as a team. Actions and ideas arising from the retrospective should be noted and implemented promptly, with the most impactful ones prioritized. The retrospective should be kept within three hours for a month-long sprint, adjusting for shorter sprints. This event marks the end of the sprint, preparing the team to begin the cycle anew

This lecture emphasizes the importance of reflection and action planning in a Scrum retrospective meeting to improve team performance and estimation accuracy during sprints. It highlights that estimating tasks involves gathering experience over time and may require guidance from more experienced team members, with adjustments becoming more accurate as the team's familiarity with the product and sprint process increases. Locking in time estimates for tickets allows for tracking actual time spent in the sprint, which aids in refining future estimates and understanding team performance. Converting tickets into actionable items for the next sprint is crucial, along with identifying responsible team members, while maintaining a separate, accessible document listing all actions ensures transparency. Continuous improvement is a core theme, encouraging reflection on workload distribution, involving external expertise for better estimation, and inviting relevant members from other departments to future sprint events. Finally, the retrospective serves as a time to reflect, inspect, and improve upon the last sprint, setting the stage for the next sprint planning session.

This segment emphasizes the importance of Scrum events in project management and encourages reflection on past work experiences. It prompts the listener to assess the effectiveness of meetings held during a project and suggests aligning them with Scrum events. The importance of planning, regular communication, stakeholder involvement, and iterative development is stressed. It encourages considering whether a different approach, such as iterative planning and regular feedback, would have resulted in better outcomes. Finally, it suggests reflecting on lessons learned and the benefits of more frequent discussions on improving team dynamics and working practices.

This lecture covers how to create a new sprint board in Trello at the end of the first sprint, which is essential for migrating your backlog list to the next sprint board. You can either click "Create" at the top or navigate back to the workspace to create a new board, naming it "Sprint 2" and selecting a different background for differentiation. Once the board is created and set to be visible to the workspace, return to the Sprint 1 board, click on the list you want to move, select "Move List," and choose the newly created Sprint 2 board. After migrating the backlog, return to the Sprint 2 board to see your list transferred. Remember to invite your team members and anyone else who needs access to ensure transparency. This process effectively allows you to move your backlog from one sprint to the next, enabling you to dive into Sprint 2 and start the cycle anew.

This segment builds on the understanding of the Scrum Master and emphasizes its significance within the Scrum framework. It highlights the Scrum Master's role as a servant leader, serving the Scrum team, the Product Owner, and the organization as a whole. The upcoming lectures will delve deeper into how the Scrum Master fulfills these responsibilities.

This lecture emphasizes the vital role of the Scrum Master in serving the Scrum team by coaching members in self-management and cross-functionality, which are crucial for creating high-value increments that meet the definition of done. The Scrum Master removes impediments to the team's progress and ensures that all Scrum events take place in a positive, productive manner within their timeboxes. You'll guide interns in taking responsibility for the sprint goal while managing themselves effectively, focusing on the definition of done, and meeting expected standards. Encouraging open communication, you'll foster an environment where team members feel comfortable asking questions and raising issues. Additionally, you will work to identify and eliminate dependencies, impediments, blockers, and bottlenecks to facilitate progress. Ultimately, it's your responsibility to ensure that all Scrum events are efficient and effective while maintaining a positive atmosphere, thereby coaching the team on how to implement Scrum practices correctly.

This lecture highlights the Scrum Master's role in serving the Product Owner by assisting in the definition of effective product goals and managing the product backlog. You will support the Scrum team in understanding the importance of clear and concise product backlog items while helping to establish empirical product planning in complex environments. Your responsibilities include facilitating stakeholder collaboration as required, ensuring that the Product Owner can effectively manage the product backlog and that the Scrum team can decompose product backlog items into detailed tasks ready for the sprint. Additionally, you'll promote Scrum principles and leverage various inspection and adoption opportunities to foster empirical product planning, as well as facilitate stakeholder collaboration during events like the Sprint Review, when necessary.

This lecture emphasizes your role in serving the organization by leading, training, and coaching in its Scrum adoption. You will be responsible for planning and advising Scrum implementations, helping employees and stakeholders grasp and apply an empirical approach to complex work, and removing barriers between stakeholders and Scrum teams. Essentially, you will act as a Scrum champion, providing training and coaching while promoting the effectiveness of Scrum throughout the organization. Your responsibilities also include networking and facilitating communication between stakeholders and Scrum teams, thereby effectively selling the value of Scrum to the organization.