Scrum Master II Certification Prep & Mock Exams (SM 2)

This UNOFFICIAL course is will prepare you to take the PSM II certification which is as a step beyond PSM I. It is designed to prepare learners for the more challenging PSM II assessment. The PSM II certification, though rare, can be achieved with thorough preparation, as the assessment focuses on situational questions requiring the best possible answers among several correct ones. The lecture emphasizes the importance of reading materials like the Scrum guide and taking practice assessments, while also highlighting key concepts and overlaps between competencies. Students are encouraged to study diligently, as the pass mark is high and retakes are costly.

Trademarks

This course and all test questions, quizzes and practice exams are NOT endorsed by or affiliated with Scrum.org.

The terms such as:

• Scrum Open

• Professional Scrum™

• Professional Scrum Master™

• Professional Scrum Product Owner™

• PSPO I, PSPO 1

• PSM I, PSM 1

• and more

Are a brand of Scrum.org.

The Scrum Guide™

Anywhere in this course terms referring to "The Guide", "the Scrum Guide", "Guide" refer to the official The Scrum Guide™ which is available at https://www.scrumguides.org/.

©2018 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Scenarios

The scenarios presented in this course are fictional. Any names, businesses, products etc. mentioned in the demonstrations are fictitious. Any resemblance to actual persons, events or businesses is coincidental.

In this lecture, the focus is on the steps required to purchase and take the certification exam. The process begins with visiting Scrum.org, where you can log in, navigate to the Professional Scrum Master (PSM) certification path, and select PSM II. The lecture explains purchasing the certification for $250, which provides a redeemable token for when you're ready to take the exam. Tips are offered on timing the purchase, especially if your organization is paying for it, taking into account budget cycles and avoiding delays that could affect exam preparation.

In this lecture, the focus shifts to the preparation resources available on Scrum org. The site offers various free materials, including videos, podcasts, and books, all accessible through the "Prepare" button on the Professional Scrum Master certification page. The lecture encourages exploring the Scrum Master (PSM II) learning path, which allows users to filter by topics and search for relevant content. It's recommended to familiarize yourself with these resources to help you effectively prepare for the PSM II assessment, as Scrum.org highly endorses them.

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

In this lecture, we explore empiricism, the foundational principle of Scrum that emphasizes gaining knowledge through experience and making decisions based on observations. Scrum focuses on iterative processes where teams inspect and adapt their work, supported by the three pillars of transparency, inspection, and adaptation. Lean thinking, which reduces waste and highlights essential elements, influences sprint goals and time boxes. Key Scrum events—Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective—facilitate this iterative process. Transparency is achieved through Scrum artifacts: the Product Backlog, which outlines emergent tasks; the Sprint Backlog, representing the developers' plan; and the Increment, the tangible outcome of each sprint, all contributing to informed decision-making and continuous improvement.

In this lecture, we'll explore the format of the multiple-choice questions you'll encounter. These questions vary; some require selecting one best answer, while others may have multiple correct options, often presented in complex scenarios. You'll typically have about three minutes per question, but you can often discount incorrect answers quickly. As we progress, I’ll read the questions aloud, and I encourage you to pause and attempt answers before I reveal them. At the course's end, you'll find practice exams with explanations linked to videos. I recommend having the Scrum Guide handy, as you can use it during the certification. Familiarity with the guide will help you navigate the questions efficiently. You might notice some overlap in questions, reinforcing your understanding of Scrum. Let’s dive into the first set of questions!

In this lecture, the focus is on understanding the foundational elements of Scrum, emphasizing that Scrum is based on empiricism and lean thinking, as outlined in the Scrum guide. The lecture explores the significance of these concepts in guiding decision-making and promoting effective practices within the framework.

In this lecture, the definition of empiricism is clarified as making decisions based on what is observed and understanding that knowledge comes from experience. This approach emphasizes the importance of relying on real-world observations to inform decision-making, highlighting the value of learning through practical experience.

In this lecture, the benefits of shorter sprints in Scrum are examined. Shorter sprints provide several advantages: they create shorter feedback loops, reducing the risk of deviation; they allow for more opportunities to inspect and adapt; and they enable quicker adaptation to changes in the environment. Additionally, while shorter sprints may initially seem to require more meetings, they can actually reduce the overall time spent in sprint events by keeping them concise. It’s important to note that longer sprints do not necessarily lead to more stakeholder feedback. Overall, shorter sprints help minimize further deviations by facilitating frequent inspection and adaptation.

In this lecture, the application of empiricism in Scrum is discussed. Scrum relies on transparency through its artifacts, which are designed to provide clarity and facilitate informed decision-making during each Scrum event. Key principles include that decisions are made based on one or more artifacts, and that these artifacts are inspected regularly to inform the team's progress and learning. Scrum combines four formal events within the sprint to uphold the pillars of empiricism—transparency, inspection, and adaptation. It’s crucial to understand that while artifacts like the product backlog and sprint backlog can change as understanding evolves, they are not immutable. Additionally, lean thinking focuses on reducing waste and emphasizing essentials rather than being synonymous with empiricism. Overall, effective Scrum practices enable teams to continuously inspect and adapt, leveraging their observations to enhance their processes and outcomes.

In this lecture, the pillars of empirical process control are identified as transparency, inspection, and adaptation. These three pillars, as defined in the Scrum Guide, are fundamental to Scrum practices and will be emphasized throughout the course. Understanding and applying these pillars effectively is crucial for ensuring that teams can operate transparently, regularly inspect their progress, and adapt their processes based on their findings.

In this lecture, the impact of senior stakeholders frequently missing sprint reviews on empirical processes is examined. The absence of these key stakeholders leads to longer feedback loops, increasing the risk of significant deviations from their expectations. It also results in product backlog prioritization decisions being made with limited information, which can hinder effective decision-making regarding the increment. Additionally, stakeholders who do not attend the sprint reviews lack the necessary insights to contribute meaningfully to product decisions, further complicating the process. Ultimately, this absence not only risks the quality of decisions but also undermines the values of commitment, openness, and respect within the Scrum framework, thereby affecting overall trust among team members and stakeholders.

In this lecture, the principles of empiricism are explored, focusing on its relationship with lean thinking and the effects of the product and sprint goals. The discussion emphasizes the significance of time boxing and the empirical pillars of transparency, inspection, and adaptation in the Scrum framework. It also highlights how Scrum artifacts contribute to transparency and asserts that achieving the sprint goal serves as the best measure of sprint success. Additionally, the lecture addresses the emergent nature of the product backlog, underscoring its importance in the Scrum process.

In this lecture, we explore the importance of Scrum values in building trust and guiding team behaviors. Each Scrum artifact is linked to a commitment: the Product Backlog to the Product Goal, the Sprint Backlog to the Sprint Goal, and the Increment to the Definition of Done. The Scrum team should focus on achieving the Sprint Goal rather than merely completing tasks, as this ensures the work adds value. Additionally, respect among team members fosters an environment of collaboration, acknowledging diverse perspectives and individual capabilities. By embodying these values, the Scrum team reinforces the empirical pillars of transparency, inspection, and adaptation essential for effective Scrum practices.

In this lecture, the focus is on the importance of respect within a Scrum team, illustrated through the scenario of two developers disagreeing on a task during a daily scrum. The heated argument between them exemplifies a lack of respect, which is a crucial Scrum value that underpins effective collaboration and teamwork. The lecture emphasizes that maintaining respect is vital for fostering a positive and productive environment, and hints at further discussions on how a Scrum Master can address such conflicts.

In this lecture, the discussion revolves around a scenario where a senior stakeholder requests a developer to urgently add functionality to the Sprint backlog. It highlights that it is not inherently disrespectful for the developer to refuse this immediate request, as respect for the Scrum framework is essential. The developer should collaborate with the product owner and the Scrum team to assess whether the new request aligns with the Sprint goal and if there is sufficient capacity to accommodate it. The team must have the courage to uphold the framework, potentially exploring solutions such as adjusting the Sprint scope, delaying the task to a future Sprint, or even canceling the current Sprint if necessary.

In this lecture, the focus is on the value of courage within the Scrum framework, emphasizing that Scrum team members must have the courage to do the right thing and tackle challenging problems. This involves adhering to Scrum principles and Agile methodologies to maximize product value. A pertinent example discussed is when a key stakeholder pressures a developer to urgently add functionality to the Sprint backlog. In such a case, the courageous response would be for the developer to resist the immediate request and engage the Scrum team, including the product owner, to evaluate the request's value and its potential impact on the Sprint goal. Courage also encompasses team members speaking up about their concerns during Sprint retrospectives, fostering an environment where tough discussions can lead to better outcomes.

In this lecture, the discussion centers around a scenario where a new developer feels excluded from discussions and believes their opinions are overlooked, raising the issue during a Sprint retrospective. This situation highlights a lack of several Scrum values within the team, particularly courage, openness, and respect. The Scrum team fails to demonstrate courage by not actively seeking out and considering diverse opinions, which can indicate a fear of differing perspectives. Additionally, they lack openness in fostering effective dialogue that promotes transparency and inclusivity. Furthermore, respect is not upheld, as team members are not adequately listening to each other’s ideas. In contrast, the developer exemplifies courage by voicing their feelings of neglect, highlighting the importance of encouraging open communication within the team.

In this lecture, the focus is on how the Scrum value of courage plays a role in addressing difficult scenarios. In such cases, assessments often present challenges that require the Scrum team to work together respectfully and find solutions as a cohesive unit. A scenario might involve making tough decisions, such as whether to adjust sprint priorities or manage stakeholder pressures, and the correct response will emphasize teamwork, openness, and the courage to uphold Scrum values while finding an effective resolution.

In this lecture, the focus is on handling a challenging scenario where a Scrum team faces delays due to changes in the technical infrastructure that impact their ability to deliver increments on time. The recommended course of action for the Scrum Master is to collaborate with other Scrum teams to discuss the ordering and value of open product backlog items, which will help redefine the delivery timeline. This approach emphasizes the courage to confront tough problems and maintain transparency. Other options, such as lengthening sprints, adding developers, or removing backlog items, are not aligned with Scrum principles and should be avoided, highlighting the importance of effective communication and teamwork in problem-solving.

In this lecture, the emphasis is on the Scrum value of openness, which focuses on transparent communication regarding work processes and interactions among team members. Openness fosters an environment where individuals freely share information, ensuring nothing is hidden and facilitating transparency within the team. This transparency is crucial for effective inspection and adaptation, allowing the Scrum team to evaluate their progress and make necessary adjustments. The discussion highlights the importance of positive interpersonal interactions and open dialogues, setting the stage for further exploration of this value through relevant examples.

In this lecture, the focus is on a challenging scenario involving a product owner relying on the Scrum team's velocity to estimate a delivery date, only to discover during a Sprint retrospective that the increment was not working due to non-adherence to the definition of done. The lecture emphasizes the importance of openness and honesty within the Scrum team, highlighting that trust is compromised when team members do not communicate issues effectively. The most effective recovery strategy is for the developers to inform the product owner that the current progress is not as perceived, provide a new estimate for completing past work, and suggest addressing this work before moving on to new features. Ultimately, it is the product owner’s decision to continue or cancel the product based on this updated information, reinforcing the necessity of clear communication and commitment to Scrum principles to navigate such difficulties.

In this lecture, the emphasis is on the Scrum value of focus, which centers around prioritizing the delivery of valuable products to customers, users, and stakeholders. This value is supported by the product goal and Sprint goals, aligning with key Agile principles such as satisfying the customer through early and continuous delivery of valuable software and measuring success by working software rather than extensive documentation or the number of completed tasks. The discussion encourages Scrum teams to concentrate on releasing valuable software and not be sidetracked by achievements that do not contribute to these primary objectives. The lecture also suggests revisiting the Agile principles and the Agile Manifesto for further insights, reinforcing the importance of maintaining focus in Scrum practices.

In this lecture, the focus is on the importance of the Scrum value of focus during the Sprint retrospective. When the product owner expresses concern that the developers only just met the Sprint goal, it becomes clear that the developers' simultaneous engagement in other projects may have hindered their ability to fully concentrate on the current Sprint objectives. This lack of dedication to the Sprint goal not only reflects a failure to maintain focus but also raises questions about their commitment to the team and the project. The discussion underscores that prioritizing the Sprint goal is essential for achieving success in current and future Sprints, emphasizing the need for developers to align their efforts fully with the team's objectives.

In this lecture, we emphasize the role of the Scrum Master in ensuring that all Scrum events are effective and efficient. When observing a nine-member Scrum team struggling to adhere to the 15-minute timebox for the daily Scrum, the best response is to offer to join the meeting and teach the team how to maintain the timebox. This approach reflects the Scrum Master’s accountability for coaching the team and reinforces the importance of discipline and focus in Agile practices. It’s crucial to address the underlying issues affecting the meeting’s duration rather than accepting extensions or suggesting the division of the team without first identifying and resolving communication or focus issues.

In this lecture, we explore the interconnectedness of the Scrum values: commitment, focus, openness, respect, and courage. Understanding these values is crucial for both the assessment and practical application of Scrum. Trust is fundamental to building effective teams, and respect for the product owner’s decisions, as well as valuing diverse perspectives and experiences, is essential. Courage is necessary for addressing tough problems and making the right decisions, while openness promotes transparent communication regarding work and challenges. Lastly, focus emphasizes achieving product and Sprint goals rather than merely tracking velocity. These principles collectively form the foundation of successful Scrum practices.

In this lecture, we explore the structure and accountabilities of the Scrum team, which includes the product owner, Scrum master, and developers, each with distinct roles as outlined in the Scrum Guide. A key focus is on the Scrum Master's responsibilities, especially in managing challenging scenarios that may arise. Participants should be prepared for questions related to making the first sprint productive, team size, scaling Scrum, and the dynamics of component and feature teams. The lecture aims to equip attendees with insights into these essential aspects of the Scrum framework, providing a foundation for navigating real-world situations effectively.

In this lecture, we discuss strategies for enhancing Scrum team productivity during the first sprint. Key actions include ensuring that the definition of done is clearly understood, allowing developers to define the process for converting product backlog items into a potentially releasable increment, and encouraging the product owner to address questions regarding the product's history, goals, and context. Additionally, introducing team members to each other and sharing their backgrounds can foster a collaborative environment. We also emphasize the importance of self-management and cross-functionality within the team while acknowledging the natural challenges that arise during the forming and storming stages of team development. The Scrum Master's role is to facilitate these processes, ensuring that Scrum events are constructive and support the team's growth as they learn to work together effectively.

In this lecture, we examine Tuckman's stages of group development—forming, storming, norming, and performing—highlighting the common challenges new Scrum teams face. During the storming stage, team members may experience conflict as they push against established boundaries and their true personalities and working styles emerge, leading to friction and tension. It's essential to understand that these challenges are a natural part of the team's evolution, and it may take time for them to become high-performing. As a Scrum Master, your role is to coach the team in self-management and cross-functionality while ensuring that the Scrum framework is effectively adopted and that all Scrum events are positive and productive. We also address how these stages apply when considering changes to the Scrum team and prepare for potential questions related to these dynamics.

In this lecture, we discuss the dynamics of team member changes within a Scrum team, emphasizing that changes should occur as needed while considering the potential short-term reduction in productivity. This concept aligns with Tuckman's model of group development, which outlines that when team members change, the team will go through the forming, storming, norming, and performing stages. It is crucial for the team, organization, and stakeholders to understand that temporary decreases in velocity are normal during this transition, with the expectation that the team will ultimately become more productive as they adapt and grow together. We will explore Tuckman's model in greater depth in the self-management lecture, but for now, we will proceed to another scenario.

In this lecture, we explore how to effectively organize four Scrum teams within a Nexus framework for developing a web application, ensuring that the stakeholders receive a cohesive increment by the end of the first sprint. As a Scrum Master, the primary advice includes establishing a shared definition of done across all Scrum teams to ensure that the integrated increment is deliverable for the Sprint review. Additionally, using a single product backlog for all teams is essential to maintain coherence and alignment in priorities. Furthermore, it's crucial to empower the teams to take responsibility for forming themselves with the necessary skills to deliver an increment at the end of every sprint, including the first one. This approach ensures adherence to the Scrum framework and promotes effective collaboration among the teams, allowing for a successful product increment.

In this lecture, we delve into the principles of scaled Scrum, specifically referencing the Nexus guide, which outlines best practices for organizing Scrum teams effectively. The recommended size for development teams is typically ten people or fewer, allowing them to remain agile while completing significant work within a sprint. When teams grow too large, it's advisable to reorganize into multiple cohesive Scrum teams that share the same product owner, product goal, and product backlog, ensuring alignment and focus. The lecture emphasizes the importance of self-organization among Scrum teams, where developers are empowered to select the most suitable members for specific tasks based on their understanding of each other's strengths and weaknesses. This self-managing aspect of Scrum enables teams to optimize their performance and deliver increments of value efficiently.

In this lecture, we emphasize that the best approach to dividing a group of 50 people into multiple Scrum teams is to let the developers decide how to form their teams. This aligns with Scrum's principle of self-organization, as developers possess the best understanding of their skills, strengths, and task dependencies. Allowing them to choose their teams fosters a sense of ownership and accountability, ensuring they work together professionally and effectively. In contrast, forming teams based on functional layers or interpersonal relationships may lead to inefficiencies and misalignment with project needs, making developer-led organization the most effective strategy for delivering value.

In this lecture, we discuss a scenario where, upon joining a team as the Scrum Master, you notice a single team of 15 developers under a product owner. The recommended approach is to suggest splitting the team into smaller groups of ten or fewer and facilitate a discussion on how to achieve this division. While the Scrum Guide supports smaller teams for better communication and productivity, it’s essential to remember that the decision on team composition should come from the developers themselves. As a Scrum Master, your role is to guide this discussion and prepare stakeholders for the temporary reduction in productivity as the newly formed teams undergo Tuckman's stages of forming, storming, norming, and performing. By communicating the benefits of smaller teams, you can help stakeholders understand how this change can lead to improved collaboration and efficiency in the long run.

In this lecture, we explore the differences between component and feature teams. According to the Scrum Guide, a Scrum team should be cross-functional, and equipped with all the skills necessary to deliver value in each sprint. Component teams tend to specialize in specific areas, such as databases, front-end design, or security. This specialization can lead to multiple dependencies among teams and hinder effective communication, as each team focuses on its narrow expertise rather than the overall product. While there are advantages to having in-depth knowledge in specific areas, Scrum emphasizes the importance of feature teams. These teams are designed to develop a product from start to finish, enabling them to work collaboratively on various layers of a feature without relying on external specialists. For instance, in developing a new in-game currency for a mobile app game, a feature team would possess all the necessary skills to deliver the complete feature end-to-end, enhancing creativity and problem-solving. Understanding this distinction between component and feature teams is crucial for the PSM II assessment.

In this lecture, we explore the critical factors to consider when transitioning from component teams to feature teams in an engineering branch. It's essential to recognize that feature teams will require time to become productive as members from various functional layers learn to collaborate effectively. Initially, productivity may decline, measured in lines of code or story points, but the overall delivery of business value is likely to increase. This reflects the Tuckman stages of group development, where temporary productivity dips can occur as teams form. It's important to understand that Scrum can be adopted progressively, without needing fully functional feature teams from the start. Finally, focusing on productivity comparisons across teams should be avoided, as Scrum emphasizes delivering value over the volume of work, promoting a culture centered on achieving sprint goals and providing value to customers.

In this lecture, we discussed the importance of cross-functional product development teams for Scrum's success. While Scrum encourages transitioning to feature teams, maintaining existing component teams—such as design, database, back-end, and front-end—offers certain benefits. These teams often experience less initial disruption due to their established working relationships, leading to more predictable productivity as they adapt and discover effective collaboration methods. However, it's essential to note that while component teams may appear beneficial in the short term, they don't necessarily possess all the required skills to deliver complete increments of value. Ultimately, Scrum promotes the formation of feature teams for their long-term advantages. Additional resources will be provided for further exploration of the pros and cons of both team structures.

In this lecture, we acknowledge that while component and feature teams may be slightly out of scope for this course, they play a significant role in understanding team structures in Agile environments. I'll provide links in the resource section for further reading. Each approach has its pros and cons, but it's essential to remember that Scrum advocates for feature teams, which promote cross-functional collaboration and holistic product development.

In summary, this lecture has addressed the composition of the Scrum team and their respective accountabilities. We explored the formation of new Scrum teams and Tuckman's stages of group development, which will be further examined in the self-management section. We discussed the initial drop in short-term productivity that can occur during changes to Scrum teams and reviewed scaled Scrum, including recommendations for the ideal team size. Lastly, we covered the differences between component and feature teams, emphasizing the importance of feature teams in Scrum practices.

In this lecture, we will delve into Scrum events, which you should already be familiar with from the PSM I course. While the basics are straightforward, there are additional aspects to understand for the PSM II, including concepts related to scaled Scrum. You'll be tested on why Scrum events are time-boxed and recurring, focusing on how they facilitate inspection and adaptation. Additionally, we’ll discuss strategies for addressing situations where the Scrum team may be resistant to adhering to the Scrum events outlined in the Scrum Guide. To begin, I’ll pose a few easy questions to refresh our understanding.

In this lecture, we explore the first event of the sprint, which is Sprint Planning. It's important to note that while the sprint itself serves as a container for all Scrum events, Sprint Planning initiates the sprint by defining the work to be accomplished. Therefore, both the sprint and Sprint Planning essentially start simultaneously. However, a common misconception might arise regarding the timing of backlog refinement; it's essential to clarify that backlog refinement is not considered one of the official sprint events.

In this lecture, we emphasize the time allocations for various Scrum events within a one-month sprint. Sprint Planning should not exceed eight hours, while the Daily Scrums are limited to a maximum of 15 minutes. The Sprint Review can last up to four hours, and the Sprint Retrospective should not exceed three hours. Understanding these time constraints is crucial as we move forward and tackle more questions related to Scrum events.

In this lecture, we focus on the continuity of sprints within Scrum. The maximum amount of time between the conclusion of one sprint and the start of the next is effectively nonexistent; a new sprint starts immediately after the previous sprint concludes. This consistency is vital, as sprints are fixed-length events lasting one month or less, as outlined in the Scrum Guide.

In this lecture, we discuss the daily scrum and the questions that should be addressed during this event. Contrary to common belief, the daily scrum does not have prescribed questions from the Scrum Guide, such as "What did I do yesterday?" or "What do I plan to do today?" While these questions are popular for guiding discussions, the Scrum Guide emphasizes that the daily scrum should focus on progress toward the sprint goal and produce an actionable plan for the next day's work. The daily scrum is a 15-minute event specifically for the developers of the Scrum team, held consistently at the same time and place throughout the sprint. While the Product Owner and Scrum Master may participate if actively working on sprint backlog items, it's the developers who are primarily required to attend. The Scrum Master ensures the event takes place, adheres to the time box, and remains positive and productive.

In this lecture, we emphasize the purpose and structure of the daily scrum as defined in the Scrum Guide. The daily scrum serves to inspect progress toward the sprint goal and adapt the sprint backlog as necessary, ensuring that the upcoming planned work is aligned with the team's objectives. This 15-minute event is specifically for the developers of the Scrum team and is held at the same time and place every working day of the sprint to minimize complexity. If asked who needs to attend the daily scrum, it's important to note that only the developers are required; however, the Product Owner and Scrum Master may participate if they are actively working on items in the sprint backlog. The Scrum Master is accountable for ensuring that the daily scrum occurs, adheres to its 15-minute time box, and maintains a positive and productive atmosphere. If questioned about the structure, I'd explain that the Scrum Guide highlights the importance of these elements to enhance focus and collaboration within the team.

In this lecture, we discussed the importance of maintaining daily scrums, especially for teams working across different time zones. As a Scrum Master, I would emphasize the value of these daily meetings as crucial opportunities for the team to inspect progress, adapt their plans, and foster communication to prevent feelings of disconnection. I would address the risks associated with reducing the frequency of daily scrums, such as potential deviations from the Sprint goal and the likelihood of inaccurate Sprint plans. While advocating for daily scrums, I would encourage team ownership by facilitating discussions and consensus on any adjustments they feel are necessary. Ultimately, the structured nature of Scrum events minimizes the need for additional meetings, and while ongoing communication is essential, the daily scrum provides a reliable framework for collaboration.

In this lecture, we highlight that Scrum events are specifically designed to enable transparency and provide formal opportunities for inspection and adaptation. The daily scrum is crucial for the team to assess progress toward the Sprint goal and adjust their plans as necessary. These timeboxed events come with defined boundaries, allowing self-managed teams to focus and optimize their time around specific purposes. This structured approach facilitates efficient decision-making and helps maintain workflow by establishing deadlines, ensuring discussions remain productive and on track.

In this lecture, we discuss the role of the Scrum Master in facilitating solutions within self-managing teams. The best approach for a Scrum Master facing challenges in hosting daily scrums is to initiate a discussion, allowing developers to determine their own solutions. This empowers the team and aligns with Scrum principles, as the Scrum Master should guide discussions rather than impose decisions. While options like dividing teams or suggesting tools may arise, the emphasis should remain on collaborative problem-solving. If issues persist without resolution during the Sprint retrospective, the Scrum Master should proactively address them to ensure the team finds an effective way forward.

In this lecture, we explore a scenario where a Scrum team considers implementing a semi-frequent hardening and release sprint. The Scrum Master should emphasize that if a sprint is needed to stabilize the product, it indicates underlying development debt that must be addressed. The team should review their definition of done, as it appears insufficient to ensure a stable environment for release, and investigate their adherence to it in every sprint. While Scrum does not endorse specific sprints like hardening sprints, the need for one suggests that either the definition of done is not being followed or is not stringent enough. This situation can be addressed through a facilitated discussion or during the Sprint retrospective to identify solutions within the Scrum framework, ensuring that the product owner considers any development needs in the product backlog before introducing new features.

In this lecture, we examine how to decide the best way and location to hold the daily scrum. According to the Scrum Guide, the daily scrum is a 15-minute event for the developers of the Scrum team, and it should be held at the same time and place every working day of the sprint to reduce complexity and ensure that all members can attend consistently. While there are no specific requirements for the location, it is essential to choose a place that works best for the developers, such as around the scrum board, as this promotes engagement and collaboration. Ultimately, the decision should be made by the developers themselves, taking into account factors like accessibility, comfort, and the ability to maintain focus during the meeting.

In this lecture, we summarized the key aspects of Scrum events, including their duration for a month-long sprint and the significance of timeboxes for supporting inspection and adaptation. We addressed how to manage situations when teams are reluctant to adhere to the Scrum framework and highlighted the three critical questions to ask during the daily scrum. It's important to note that only developers need to attend the daily scrum, which should be held at the same time and place every day to simplify the process. We also discussed the feedback loop created by Scrum events, emphasizing the necessity of having a daily scrum to address problems promptly. Finally, we reaffirmed that the Scrum framework does not support special sprints, such as hardening sprints or sprint zeros, as the focus should remain on the regular structure of Scrum events.

In this lecture, we recapped the key Scrum artifacts: the product backlog, the sprint backlog, and the increment, each accompanied by a specific commitment: the product goal, the sprint goal, and the definition of done. These artifacts are designed to maximize transparency of essential information, ensuring that everyone inspecting them shares a common understanding for making informed adaptation decisions. This transparency is critical for effective collaboration and responsiveness within the Scrum framework. Now, let's explore a question related to these artifacts.

In this lecture, we explored the commitments associated with Scrum artifacts and the corresponding inspection points. The three main artifacts with commitments are the increment, the sprint backlog, and the product backlog. Specifically, the increment's commitment is to the definition of done, which is inspected at the Sprint Review; the sprint backlog's commitment is to the Sprint Goal, inspected at the Daily Scrum; and the product backlog's commitment is to the product goal, inspected during Sprint Planning and the Sprint Review. These commitments enhance transparency and provide clear benchmarks for measuring progress, enabling teams to align their efforts with the overarching product goal.

In this lecture, we explored the product backlog as an ordered and emergent list of tasks aimed at enhancing the product, emphasizing that backlog items must be deemed "ready" to be selected for a sprint, with developers responsible for sizing the effort required. We discussed the Sprint backlog, formed during Sprint Planning through key questions about value, accomplishable work, and execution, with the Sprint Goal serving as a single objective to maintain focus and collaboration. It is crucial to understand that achieving the Sprint Goal may not require completing all items in the Sprint backlog, as new tasks may arise and adjustments may be needed. Finally, we highlighted that the increment represents a tangible step toward the product goal, needing to integrate with previous increments for continued functionality and value.

In this situation, if three Scrum teams are working in a Nexus on the same product and each team presents their increments independently in different environments at the Sprint Review, it is indeed cause for concern. The increment should be verified as working with all other increments before it can be deemed ready for release. In a Nexus setup, where multiple Scrum teams are collaborating toward a common increment, all outputs must be integrated into a single environment to ensure they function cohesively. This integration should be part of a shared definition of done, clearly outlining that increments need to be integrated. Therefore, displaying outputs in separate environments indicates a failure to meet this definition, as the goal is to present a fully integrated increment that works with all other increments of the product.

In this lecture, we discuss the requirement for each sprint to produce at least one increment, including the first sprint. While it's permissible to have multiple increments in a single sprint, teams should not delay releasing these increments until the Sprint Review. The Scrum Guide clearly states that the Sprint Review should not serve as a gate for releasing value; increments can be released as soon as they are ready, regardless of the review timing.

In this lecture, we clarify that an increment is officially considered "born" once it meets the definition of done. The key question here is who within the Scrum team has the authority to update or change this increment. The answer is that only the developers can make changes to the increment. They are the members of the Scrum team responsible for creating any aspect of a usable increment each sprint, making them best suited to understand the implications and risks associated with modifications.

In this lecture, we reviewed the Scrum artifacts and their associated commitments, highlighting that the product backlog is emergent and emphasizing the developers' role in sizing items within the sprint backlog. We discussed the importance of having a single sprint goal crafted during Sprint Planning, the flexibility of the Sprint backlog to negotiate scope with the product owner as needed, and the team's focus on achieving the sprint goal rather than merely measuring velocity, which serves as a tool for forecasting capacity rather than evaluating sprint success. We also noted that an increment is deemed complete when the definition of done is met and identified that only developers can modify it. Lastly, we touched on the implications of an insufficient definition of done and introduced the concept of technical debt, which will be explored further in the upcoming "Done" lecture.

In this lecture, we explored the concept of "done," emphasizing that the definition of done serves as a commitment to the increment. It establishes quality standards that the increment must meet, ensuring transparency regarding expectations for readiness before release. According to the Scrum Guide, the definition of done is a formal description of the state of the increment when it meets the required quality measures, and an increment is born once a product backlog item fulfills this definition. If an item does not meet the definition of done, it cannot be released or presented during the Sprint Review; instead, it reverts to the product backlog for future consideration. The definition of done should be treated as a minimum standard—while teams can enhance it, they cannot lower it. If the definition of done aligns with organizational standards, all Scrum teams must adhere to it; otherwise, the Scrum team should create an appropriate definition of done for their product. In scaled Scrum scenarios, multiple teams working on an increment should collaboratively establish and comply with a shared definition of done. Now, let’s delve into some potential questions regarding this topic.

In this lecture, we examined the best descriptions of the definition of done. The definition of done is crucial as it creates transparency of the state of the increment for inspection at the Sprint Review, guides the developers during Sprint Planning when creating a forecast for items, and helps developers identify the remaining work necessary for an increment to be ready for release. As outlined in the Scrum Guide, the definition of done is a formal description of the increment's state when it meets the required quality measures for the product. It ensures that everyone has a shared understanding of what work was completed as part of the increment. If a product backlog item does not fulfill the definition of done, it cannot be released or presented at the Sprint Review; instead, it will revert to the product backlog for future consideration.

In this lecture, we highlighted that the measure of success in a sprint is achieving the sprint goal rather than merely counting the number of completed items. While completing items can indicate a team's work velocity, this metric should only serve as a guide for forecasting future sprint capacity. For instance, if you are a Scrum Master overseeing three teams working on the same product and management wants to assess their velocity, your best responses would be that there is no direct relationship between velocity and value, as the value of the increment to stakeholders is measured through other means. Additionally, velocity is unique to each Scrum team and represents the amount of business functionality they deliver in a sprint, serving primarily as a tool for that team to forecast their capacity for upcoming sprints. This understanding helps maintain focus on value delivery rather than simply optimizing velocity. For further insights into measuring value, one might refer to the PSPO certification and the Evidence-Based Management (EBM) guide.

In this lecture, we discussed a scenario from the Sprint Retrospective where the Scrum team faced quality challenges that hindered the completion of a proper increment at Sprint End, despite achieving high velocity. The two best responses from the Scrum Master in this situation are to stress the value of work in software over measured velocity and to facilitate a discussion on how to improve quality to ensure the increment is releasable, even if it results in a drop in measured velocity for the next sprint. It's crucial to focus on the quality of the increment rather than just the quantity of work done. The Agile Manifesto emphasizes that the highest priority is to satisfy the customer through the early and continuous delivery of valuable software. Thus, achieving a high velocity is meaningless if the sprint goal isn't met and a releasable increment isn't produced. During the retrospective, the team should examine the definition of done and consider enhancing it to ensure that all increments meet the required quality standards for release.

In this lecture, we explore the implications of a Product Owner's proposal to reduce the definition of done to accelerate release progress. As a Scrum Master, it's crucial to highlight the risks of introducing technical debt, which can lead to unknown errors and make future development unpredictable. Emphasizing that this approach creates false assumptions about the product's state is essential, as it may harm user experience and the team's reputation. Facilitating a discussion with the team about the underlying issues causing slow releases can help clarify their objectives and evaluate if a lower definition of done still allows for releasable increments. By exploring alternative solutions that enhance efficiency without compromising quality and discussing the topic in the next Sprint Retrospective, the Scrum Master can guide the team toward sustainable practices while maintaining high standards.

In this lecture, we discuss the evolving nature of the definition of done as Scrum teams mature, emphasizing the importance of continuously enhancing quality criteria. While expanding the definition can lead to higher standards, it may also reveal the need to revisit previous increments to align them with the new criteria. For instance, it's important to recognize that not all product backlog items added to the Sprint backlog must be completed by the end of the sprint; this statement is false. The definition of done serves as a commitment to the increment, establishing a shared understanding of the minimum quality needed for a potentially releasable increment. As the team progresses through the sprint, the sprint backlog may need to adapt based on new information, allowing for the removal of certain tasks or the addition of new items to ensure alignment with the sprint goal.

In this lecture, we emphasize that the concept of "done" is encapsulated in two key definitions: having an increment of working software that is potentially releasable to end users and ensuring that all work performed aligns with the criteria outlined in the definition of done. These aspects underscore the necessity for quality and readiness in increments, reflecting a shared understanding of completion among the Scrum team.

In this lecture, we discuss the actions to take when a product backlog item in the Sprint backlog does not meet the team's definition of done by the end of the sprint. The two necessary steps are to not include the item in the increment for the sprint, as it does not meet the criteria for being potentially releasable, and to estimate the remaining work needed to make it done. This estimate should then be added to the product backlog for the Product Owner to decide on the item's future. These actions ensure that all items presented in the increment satisfy the complete definition of done, as outlined in the Scrum Guide.

In this lecture, we address the importance of documentation and testing in the definition of done and consider a scenario where the technical writer is on holiday during the sprint. The key takeaway is that the Scrum team is accountable for meeting the definition of done, meaning the developers should write the technical documentation themselves. As the individuals who are best placed to do so due to their involvement in creating the product, they should ensure that all necessary documentation is completed. This highlights the cross-functional nature of Scrum teams, emphasizing that all members share responsibility for upholding the standards set in the definition of done.

In this lecture, we explore key concepts from the Nexus guide, particularly focusing on scaled Scrum when multiple teams collaborate on a product. It's crucial for these Scrum teams to frequently integrate their work into a common environment for testing, ensuring that the integration aligns with the shared definition of done. This mutual agreement on the definition of done establishes consistent quality standards and fosters transparency, allowing for effective inspection and adaptation. During the Nexus Sprint review, an integrated increment is presented to stakeholders, highlighting the importance of combining all team contributions into a final, releasable increment. If teams operate in isolated environments or separate code branches, it indicates that integration has not occurred, which means the definition of done has not been met. Thus, integrating increments before the Sprint review is essential for delivering a cohesive product.

In this lecture, we discuss the necessity of including testing in the definition of done. The answer is a definitive yes: testing is mandatory to ensure that the increment is ready for release. While the specific components of the definition of done are determined by the organization and the Scrum team, testing is essential for confirming that the increment meets quality thresholds and functions as intended. Without testing, the increment's usability remains uncertain, posing risks and reducing transparency. The definition of done serves as a formal description of the increment's state when it meets the required quality measures, and testing is a critical aspect of this verification process. As highlighted in the Scrum Guide, all increments must be thoroughly verified to ensure seamless integration, further underscoring the importance of including testing in the definition of done.

In this lecture, we discussed the definition of done, emphasizing that achieving the sprint goal is the true measure of success, not velocity, which is merely a forecasting tool unique to each team. We highlighted the necessity for multiple teams to collaborate on a shared product backlog and to mutually agree on a consistent definition of done without reducing its rigor, allowing teams to enhance it but never release increments that do not meet these standards. Additionally, we noted that testing and documentation must be integral to the definition of done and explored the principles of scaled Scrum, particularly the Nexus framework, which emphasizes the importance of integrating increments within a shared environment.