Skip to content

Registered Scrum Master

Preamble

This document lays out the Learning Objectives for the Registered Scrum MasterTM course. The focus of the Registered Scrum Master acourse is on the application of knowledge and skills within and beyond the context of the course. The learning outcomes are designed to offer instructors an opportunity for reflection on the course content, to set standards by which the success of the course will be evaluated, and to provide useful methods for assessing students’ learning. Instructors should create an interactive and meaningful learning experience that incorporates their own real-world examples and practical knowledge.

Core Scrum

The Scrum Framework

  • Explain that Scrum is a lightweight framework that can be applied in any industry and domain; yet, while Scrum is adaptable to different contexts, the core framework remains the same across implementations.
  • Explain the value of agility over traditional project management in today’s rapidly changing marketplace.
  • List the five Scrum Values and explain how they relate to one another.
  • Recognize that successful use of Scrum depends on people becoming more proficient in living the five Scrum Values: Commitment, Focus, Openness, Respect, and Courage.
  • Relate hands-on experience with iterative development to their own working context.
  • Express the value of sharing learnings and insights across teams.
  • Explain that a product is a vehicle to deliver value and could be a service, a physical product, or something more abstract.
  • Give at least one example of Scrum or Scrum@Scale outside of IT.

The Origins of Scrum

  • Explain how Dr. Sutherland’s experience in making work visible at West Point lead to the transparency emphasized in Scrum today.
  • Recognize the influence that Dr. Sutherland’s experience as a fighter pilot, responding to change over following a plan, has had on Scrum.
  • Recognize how Dr. Sutherland’s background working as a cancer researcher gave rise to a statistical understanding of which small steps lead to healthier change, and that each small step will open or close doors in the evolution of a system.
  • Describe the OODA loop as it relates to overcoming resistance to change.
  • Discuss the significance of ’2-sword combat’ (e.g., balancing short and long term needs and goals) and ’winning a war without firing a single shot’ (e.g., an Agile transformation without firing a single person) in the context of business.

The Scrum Team

  • State that the fundamental unit of Scrum is the Scrum Team, which consists of one Scrum Master, one Product Owner, and Developers.
  • Explain that the Scrum Team is a cross-functional, cohesive unit of professionals focused on the Product Goal, and is self-managing, meaning they internally decide who does what, when, and how.
  • Distinguish the three Scrum roles, identify what each is accountable for, and explain how they work together to balance quality, sustainability, and the creation of business value with a focus on the customer.
  • Describe the benefits of cross-functional teams over siloed teams.
  • Explain the value of T-shaped Team Members and identify techniques for encouraging T-shaped growth and development.
  • Discuss why Scrum Teams should be small & stable, collaborative, self-managing and self-organizing.
  • Recognize that the Scrum Master and Product Owner are part of the Scrum Team, not apart from it

Developers

  • Recognize that the word "Developers" in Scrum is intended to simplify, not exclude, and applies to all individuals on the Scrum Team who are working on the Increment, regardless of industry or domain.
  • State that the Developers own the ‘how’ and have autonomy over the techniques they use to achieve the Product Goal.
  • Explain that Developers are accountable for:
    • Creating a plan for the Sprint, the Sprint Backlog.
    • Instilling quality by adhering to a Definition of Done.
    • Adapting their plan each day toward the Sprint Goal.
    • Holding each other accountable as professionals.

Scrum Master

  • Describe how and why the Scrum Master owns the Scrum process.
  • Explain why the Scrum Master should focus on speed and shortening the feedback loop while helping the team maintain a sustainable pace.
  • Explain why the Scrum Master is accountable for improving the Scrum Team’s effectiveness.
  • Recognize that the Scrum Master is a true leader who serves the Scrum Team and the larger organization by coaching them on the Scrum process; making work visible; ensuring that the Scrum Events take place and are positive, productive, and kept within the time-box; causing the removal of impediments the Scrum Team’s progress; and maintaining a focus on continuous improvement.
  • Explain why the Scrum Master and Product Owner are a pair and must work together to implement the Scrum and Agile values, find techniques for effective Backlog management, collaborate with stakeholders, and clearly communicate the vision, priority, and goals to the team.
  • Provide real-world examples of Scrum Master challenges and propose ways of addressing them.

Product Owner

  • State that the Product Owner is accountable for maximizing the value of the work done by the Scrum Team.
  • Explain why the Product Owner is responsible for clearly communicating the Product Goal to the team and for developing a Backlog to achieve that Product Goal.
  • Recognize that the Product Owner has the final say on the ordering of the Product Backlog.
  • Describe why the Product Owner should spend half of their time with customers and stakeholders and the other half of their time with the Scrum Team.
  • Explain that for Product Owners to succeed, the entire organization must respect their decisions.

Leadership/Management

  • Discuss the notion of servant leadership and explain how this differs from traditional command and control management.
  • Explain why servant leadership is key to building an agile system.
  • Explain why leadership must create the environment and culture for Scrum to succeed.
  • Explain why leadership is responsible for eliminating organizational debt.
  • Distinguish areas of waste and areas of value in traditional management practices.
  • Describe how the value-add responsibilities of traditional project management are distributed across the three Scrum Roles.
  • Give an example of servant leadership.

Scrum Events

The Sprint

  • Recognize the Sprint as a fixed time-box of one month or less, in which the team produces a “done” Product Increment.
  • Explain the importance of having a stable Sprint cadence, especially with regard to Velocity.
  • Describe why shorter Sprint cycles are preferred to longer Sprint cycles.
  • Explain that during the Sprint, no changes are made that would endanger the Sprint Goal, and only the Product Owner has the authority to cancel the Sprint.

Product Backlog Refinement

  • Recognize that the Scrum Team should dedicate up to 10% of their Sprint length to refining the Product Backlog.
  • Recognize that Product Backlog Items (PBIs) can be any size and become more granular and detailed as they get closer to execution.
  • Create PBIs using a format that incorporates the "who," "what," and "why" (e.g., user story format).
  • Explain why we want to get PBIs in a “ready” state and give examples of ‘Definitions of Ready.’
  • Distinguish ‘Definition of Done’ from ‘Acceptance Criteria.’
  • Apply story-slicing techniques that enable swarming on PBIs.
  • Recognize that the Product Backlog can change at any time.
  • Explain that if the Definition of Done is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
Estimation
  • Discuss why only those doing the work estimate it.
  • Recall at least two empirically supported reasons for why estimating in points is better than estimating in time.
  • Describe relative size estimation, which may include estimates of effort or value.
  • Identify at least two methods for estimating PBIs with points (e.g., planning poker and affinity estimation).
  • Practice estimating PBIs using points

Sprint Planning

  • Explain that the Sprint Backlog is made up of the Sprint Goal, the Product Backlog Items selected for the Sprint, plus the plan for delivering them.
  • Recognize that Sprint Planning is time-boxed to two hours (or less) per week of Sprint.
  • Explain that Sprint Planning addresses three topics: Why the Sprint is valuable, What can be Done in the Sprint, and How the chosen work will get done.
  • Discuss real-world examples of the three topics covered in Sprint Planning.
  • Describe the importance of having a Sprint Goal that is motivating and achievable.
  • Recognize that the Scrum Master should help the team confirm their capacity so they know how much work to pull into the Sprint.
  • Discuss why only “ready” PBIs should be pulled into the Sprint Backlog.
  • State that the Sprint Backlog is one of the three Scrum artifacts.
  • Explain that a Kaizen, or process improvement experiment, should be at the top of the Sprint Backlog.

Sprint Review

  • Explain that the purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
  • Explain that the Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
  • State that the Sprint Review is time-boxed to one hour (or less) per week of Sprint.
  • Describe that the objective of the Sprint Review is to demonstrate a working increment for the purpose of getting feedback and updating the Product Backlog.
  • Explain that only work that has met the Definition of Done is demonstrated at the Sprint Review.
  • Explain that the Product Owner is responsible for getting the right people in the room to give feedback and collaborate during the Sprint Review.
  • Discuss the impact of any work that was pulled into the Sprint Backlog but, for one reason or another, did not get done.

Sprint Retrospective

  • State that the Sprint Retrospective is time-boxed to 45 minutes (or less) per week of Sprint.
  • Describe the purpose of the Sprint Retrospective and the importance of the Retrospective for continuous improvement.
  • Discuss the importance of the Scrum Team identifying and agreeing on a measurable process improvement experiment (Kaizen) to try in a future Sprint based on reflection of previous Sprint.
  • Explain that during the Sprint Retrospective, the Scrum Team discusses what went well during the Sprint, what problems were encountered, and how those problems were (or were not) solved.
  • Relate the importance of identifying the current state and target condition when deciding on experiments for improving the process.
  • Differentiate velocity trends for teams that practice Kaizen versus teams that don’t.
  • Demonstrate at least one method for facilitating a Sprint Retrospective.

Daily Scrum

  • Describe the purpose of the Daily Scrum as a meeting for the Developers to inspect progress toward the Sprint Goal, identify and remove impediments, and adapt their plan for the next day of work so they are better able to achieve the Sprint Goal.
  • Explain that the daily scrum intensifies focus, improves communication and promotes quick decisionmaking.
  • Explain why the result of the Daily meeting should reflect improved flow (and Process Efficiency of PBIs).
  • State that the Daily Scrum is time-boxed to 15-minutes per day and should take place at the same time and location each day of the Sprint.
  • Identify techniques for motivating team spirit and maximizing the effectiveness of the Daily Scrum.
  • Explain how the Daily Scrum can be used in a scaled context to align multiple teams that have a common goal or a need to coordinate.
  • Recognize symptoms of an unhealthy Daily Scrum and an unhealthy Scrum board.
  • Explain the Scrum Master’s role in the Daily Scrum.

Scrum Artifacts

  • Identify the three Scrum Artifacts (Product Backlog, Sprint Backlog) and how they are produced in, or help guide, the five Scrum events.
  • State the commitment for each Scrum Artifact (Product Goal, Sprint Goal, Definition of Done) and explain its purpose

Lean Principles

  • Describe a Kaizen mindset and explain how small, iterative changes can lead to revolutionary leaps.
  • Describe the three pillars of Scrum – Transparency, Inspection, and Adaptation,– which implement the work of Ogunnaike and Ray.
  • Explain the importance of reducing and eliminating waste in the system.
  • Perform a root-cause analysis (e.g., using the ‘5 Whys’ technique).
  • Assess the Process Efficiency of their Scrum Team and recall that the definition of Lean is a Process Efficiency of 25% or higher.
  • Explain how the work of Takeuchi and Nonaka on Lean and the Toyota Production System paved the way for Scrum.
  • Describe the origins of the name ‘Scrum’ from Takeuchi and Nonaka’s ‘New New Product Development Game.’
  • Recognize that a Lean mindset suggests that you address a defect immediately after it is identified as opposed to a mindset where defects are stored to be fixed later.

Agile Manifesto

  • Recognize the four values of the Agile Manifesto and their significance in the context of complex adaptive systems.
  • Identify the 12 principles of the Agile Manifesto and describe their function in guiding practices that support teams in implementing and executing with agility.
  • Explain that Scrum is one of the driving forces that gave rise to the Agile movement and predates the Agile Manifesto.
  • Explain why the majority of “Agile” teams are late, over-budget, and with unhappy customers (i.e., not agile) and explain what needs to be done to fix that

Patterns for High-Performing Teams

  • Recommend multiple ways to double a Scrum Team’s production in one Sprint.
  • Identify which of the Patterns are generative and promote or enhance the effectiveness of other patterns, and explain how.
  • Explain the advantage of adding the Patterns to Scrum to achieve increased productivity.
  • Recognize the evidence-based nature of the Patterns in the Scrum Pattern Language.

Yesterday's Weather

  • Apply Yesterday’s Weather to determine how much work should be pulled into a Sprint.
  • Explain how this Pattern is generative to the Pattern of ‘Teams that Finish Early Accelerate Faster.’

Happiness Metric

  • Explain that happiness is a leading indicator of productivity.
  • Describe why maintaining a sustainable pace is important for happiness.
  • Apply the Happiness Metric pattern to assess the happiness of their teams.
  • Demonstrate how this pattern can be used to facilitate conversation during the Sprint Retrospective.

Teams That Finish Early Accelerate Faster

  • Explain the rationale behind not committing to more work than the team has been able to complete in previous Sprints.
  • Describe how the ‘Yesterday’s Weather’ and ‘Interrupt Buffer’ patterns reinforce the ‘Teams that Finish Early Accelerate Faster’ pattern.

Stable Teams

  • Recite Brook’s law and describe how it relates to the ‘Stable Teams’ pattern.
  • Discuss the cost of context switching and how this impacts unstable teams.
  • Explain why team performance and effectiveness improves for Stable teams.

Swarming

  • Explain what Swarming is.
  • Explain that teams that don’t Swarm are less likely to meet their Sprint commitments.
  • Describe the cost of context switching and the impact Swarming has on Process Efficiency, throughput and quality.

Interrupt Buffer

  • Determine the amount of interrupts that should be planned for based on Yesterday’s Weather.
  • Recognize that the Product Owner should still prioritize interrupts that are brought into the interrupt buffer.
  • Explain that when the interrupt buffer is full, new interrupts that are higher priority than other PBIs in the Sprint Backlog will cause the Sprint to be aborted and the team must re-plan the remainder of the Sprint.
  • Describe how this pattern can help reduce interrupts and lead to Finishing Early, making it a generative pattern.

Good Housekeeping (formerly Daily Clean Code)

  • Describe the Toyota Production System’s Andon Cord approach to dealing with defects and how this approach and mindset encourages Swarming, making it another generative pattern.
  • Recognize the impact and cost of fixing a defect outside of the Sprint.
  • Discuss how to deal with defects discovered inside versus outside of the Sprint differently.

Scrum Emergency Procedure

  • Explain what to do when it becomes obvious by mid-Sprint that the Sprint will fail.
  • Identify the steps in the Scrum Emergency Procedure in the correct order: Innovate > Offload Backlog

    Reduce Scope > Abort the Sprint

Scrum@Scale

Descaling

  • Recognize that having different interpretations of Scrum across teams will present significant challenges when scaling a Scrum implementation.
  • Explain the importance of descaling, running a Lean scrum, and starting with a small group of teams that get Scrum working well before scaling.
  • Recognize that dysfunctions at the team-level will only be magnified at scale.

Scaling the Scrum Master

  • Explain how the Scrum Master role scales in Scrum@Scale.
  • Recognize the Scrum of Scrums Master (SoSM) as a new role in Scrum@Scale.
  • Identify the Executive Action Team (EAT) as the Scrum Master for the organization.
  • Distinguish Scrum Of Scrums (SoSs) as a team of teams from the Scaled Daily Scrum (SDS) as an event.
  • Describe how the SDS can be utilized to sync and align teams within a SoSs to maintain high communication saturation while encapsulating complexity and reducing communication pathways.
  • Explain how impediments that can’t be resolved by those who encounter them are escalated to those who can resolve them.

Registered Scrum Master Credential

  • Access and complete the Registered Scrum Master by Scrum Inc. exam.
  • Download their Registered Scrum Master Credential (upon successful completion of the exam).
  • Be Recognized in the International Registry of Agile ProfesstionalsTM
  • State the renewal process.