format: "syllabus/v1"
kind: "course"
code: "SPS"
title: "Scaled Professional Scrum with Nexus (SPS) with Certification"
pre:
  - title: "Pre-Course Assessment"
    description: "Complete the Scrum Master self-assessment to identify learning goals"
    resources:
      - type: "assessment"
        title: "Scrum Master Competency Assessment"
        url: "https://nkdagility.com/assessments/scrum-master"
    timeRequired: "30 minutes"
  - title: "Review Scrum Guide"
    description: "Refresh your understanding of the Scrum framework"
    resources:
      - type: "reading"
        title: "The Scrum Guide"
        url: "https://scrumguides.org"
    timeRequired: "45 minutes"

items:
  - type: "session"
    session:
      id: 1
      title: "Scaling Scrum Fundamentals & Case Study Kickoff"
      duration: 120
      content: |
        Introduces the need for scaling and the Nexus approach while reinforcing that *Scaled Scrum is still Scrum*. Explores why and when to scale Scrum versus keeping it simple. Provides an overview of the Nexus framework at a high level. Kicks off the **Surge Pricing** case study – an end-to-end scenario used throughout the course – outlining how multiple teams will collaborate on a single product with dynamic pricing features.
      learningResources:
        - title: "The Nexus Guide (Scrum.org)"
          link: "https://nkdagility.com/resources/the-nexus-guide/"
          duration: 15
          type: reading
          weight: 1
        - title: "Introduction to the Nexus Framework"
          link: "https://www.scrum.org/resources/introduction-nexus-framework-0"
          duration: 7
          type: video
          weight: 2
        - title: "Common Mistakes when Scaling Scrum"
          link: "https://www.scrum.org/resources/blog/common-mistakes-when-scaling-scrum"
          duration: 8
          type: reading
          weight: 3
      assignment:
        title: "Identify Scaling Challenges"
        content: |
          Reflect on your current organization or project and identify key challenges or pain points related to scaling Scrum. Consider how the principle *"Scaled Scrum is still Scrum"* could address each challenge.
        examples: |
          - List 2–3 issues you've observed when trying to coordinate multiple teams (e.g., inconsistent practices, duplicated work) and describe how adhering to Scrum fundamentals (like a single Product Backlog or regular inspect-and-adapt) might mitigate them.
          - For example, *"Teams A and B developed similar features separately, leading to rework. A single backlog and shared Sprint Review could have ensured alignment and avoided duplicate effort."*

  - type: "session"
    session:
      id: 2
      title: "Nexus Framework Deep Dive"
      duration: 120
      content: |
        Dives into the Nexus framework's structure and mechanics. Details the new Nexus roles, events, and artifacts that augment Scrum for scaling: the **Nexus Integration Team**, Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review & Retrospective, and the Nexus Sprint Backlog. Discusses how each addition addresses common scaling issues (like cross-team coordination and integration). Uses the Surge Pricing case to map these Nexus elements onto a realistic multi-team project.
      learningResources:
        - title: "Scaled Professional Scrum with Nexus – Practices Overview"
          link: "https://www.scrum.org/scaled-professional-scrum-nexus-practices"
          duration: 5
          type: guide
          weight: 1
        - title: "How Lola Tech Leveraged Nexus to Increase ROI and Cut Costs for Client"
          link: "https://www.scrum.org/resources/how-lola-tech-leveraged-nexus-increase-roi-and-cut-costs-client"
          duration: 10
          type: reading
          weight: 2
      assignment:
        title: "Nexus Framework Reflection"
        content: |
          Summarize the key differences between a single-team Scrum and the Nexus framework. Identify each new Nexus role, event, or artifact and explain in your own words how it helps multiple teams work together.
        examples: |
          - Create a comparison table or mind map highlighting Scrum vs. Nexus (e.g., **Scrum Master** vs **Nexus Integration Team**, **Sprint Planning** vs **Nexus Sprint Planning**). Note the purpose of each Nexus element, such as: *"**Nexus Sprint Planning** – aligns all teams around a single Sprint Goal and resolves cross-team dependencies before work starts."*
          - Write a short explanation for a colleague: *"In Nexus we have one Product Owner and one Product Backlog for all teams, plus a Nexus Integration Team that ensures the work of 3–9 teams integrates into a single shippable product increment each Sprint."*

  - type: "session"
    session:
      id: 3
      title: "Organizing Teams & Nexus Integration Team"
      duration: 120
      content: |
        Focuses on structuring people and teams in a scaled Scrum environment. Examines strategies for organizing multiple Scrum Teams around one product (feature teams vs. component teams) while minimizing dependencies. Introduces the **Nexus Integration Team** in depth – its composition, responsibilities, and how it supports the Scrum Teams to produce an integrated increment. Through the Surge Pricing case, students form Scrum Teams for the project and decide who might serve on the Nexus Integration Team, learning how to coordinate roles across teams.
      learningResources:
        - title: "The Nexus Integration Team Explained"
          link: "https://www.scrum.org/resources/nexus-integration-team-explained"
          duration: 5
          type: video
          weight: 1
        - title: "Scaling Scrum to the Limit (Growth Patterns)"
          link: "https://www.scrum.org/resources/blog/scaling-scrum-limit"
          duration: 10
          type: reading
          weight: 2
      assignment:
        title: "Design a Scaled Team Structure"
        content: |
          Develop a high-level team organization plan for a Nexus working on a single product. Decide how you would split into 3–9 Scrum Teams and outline the role of a Nexus Integration Team in your context or the case study.
        examples: |
          - Using the Surge Pricing scenario (or a project of your choice), propose a team breakdown: e.g., **Team 1:** Pricing Algorithm, **Team 2:** Mobile App UI, **Team 3:** Web Portal, etc. Explain how these teams align to features and minimize overlap.
          - List who could be in the Nexus Integration Team (by role or skill) and what they would focus on (e.g., integration testing, build automation, resolving cross-team technical issues). *"For instance, one member from each team plus a Scrum Master form the Nexus Integration Team to ensure code from all teams integrates daily without conflicts."*

  - type: "session"
    session:
      id: 4
      title: "Organizing the Work & Managing Dependencies"
      duration: 120
      content: |
        Covers techniques for organizing and refining the work in a multi-team environment. Emphasizes maintaining a single Product Backlog and making dependencies visible. Students learn how to use **Product Backlog refinement** at scale to identify and address cross-team dependencies before Sprint Planning. Practices such as User Story Mapping are introduced to help slice work and allocate Product Backlog Items across teams. The importance of a **shared Definition of Done** is reinforced to guarantee that all teams deliver "Done" increments that integrate. In the Surge Pricing case study, the class refines backlog items (e.g. pricing engine, UI integration stories) and collaboratively drafts a Nexus-wide Definition of Done covering integration criteria.
      learningResources:
        - title: "Nexus Explanation – Scaling Scrum (Scott Richards)"
          link: "https://scottagile.medium.com/nexus-explanation-scaling-scrum-4ae1ccbd62b"
          duration: 6
          type: reading
          weight: 1
        - title: "Mapping User Stories for a Large Product"
          link: "https://www.nngroup.com/articles/user-story-mapping/"
          duration: 10
          type: reading
          weight: 2
      assignment:
        title: "Shared Definition of Done Draft"
        content: |
          Create or refine a **Definition of Done (DoD)** that would apply to all teams in a Nexus. Ensure it includes quality criteria and integration steps required for a potentially releasable, integrated increment each Sprint.
        examples: |
          - Draft 5–7 DoD bullet points that cover integration concerns (e.g., *"Code from all teams merged to a single repository and built successfully,"* *"End-to-end regression tests passed,"* *"All new features documented across teams"*).
          - If you already have a DoD for one team, expand it for multiple teams. For example: *"Previously, our DoD said 'All acceptance tests pass.' Now for Nexus, add '…and all team code is integrated with no new integration bugs.'"* Ensure the DoD would hold true for the entire Nexus increment.

  - type: "session"
    session:
      id: 5
      title: "Nexus in Action: Sprint Planning & Daily Coordination"
      duration: 120
      content: |
        Brings the Nexus framework to life by simulating Sprint execution events. Students experience **Nexus Sprint Planning**, where representatives from each team align on a single Nexus Sprint Goal and coordinate what each team will deliver. They learn to create a **Nexus Sprint Backlog** that highlights all teams' selected items and inter-team dependencies. The session also covers how individual Scrum Teams then do their own Sprint Planning in the Nexus context. Additionally, the **Nexus Daily Scrum** is introduced as a daily forum for teams to share progress on the integrated increment and address new dependencies or integration issues. Using the Surge Pricing case, learners practice a scaled Sprint Planning: for example, teams plan Sprint 1 together to build and integrate a surge pricing engine and UI updates, negotiating who works on which backlog items and identifying touchpoints between teams.
      learningResources:
        - title: "Nexus Sprint Planning (Multi-team Coordination)"
          link: "https://kendis-io.medium.com/nexus-sprint-planning-5c22d35a8b28"
          duration: 3
          type: reading
          weight: 1
        - title: "Tips for Scaling Scrum (Scrum Tapas Video)"
          link: "https://www.scrum.org/resources/tips-scaling-scrum"
          duration: 6
          type: video
          weight: 2
      assignment:
        title: "Scaled Sprint Goal & Plan"
        content: |
          Define a Nexus Sprint Goal and outline a brief Sprint plan that coordinates multiple teams. Imagine you are preparing for a Nexus Sprint Planning – determine a common Sprint Goal and how a few teams could each contribute to it.
        examples: |
          - For the Surge Pricing product, propose a Nexus Sprint Goal like: *"Enable surge pricing calculation in the booking system (basic end-to-end functionality)"*. Then list what Team A and Team B would each do to support that goal (e.g., *Team A: develop backend pricing algorithm; Team B: integrate UI changes to display surge price*), noting any dependency (Team B needs an API from Team A by mid-sprint).
          - In your own environment, if you had two teams, outline a shared Sprint Goal and a coordination plan. *For example: "Sprint Goal: Improve load performance by 20%. Team 1 will optimize backend code; Team 2 will refine the database indexing. They'll check integration at mid-Sprint to measure combined performance."*

  - type: "session"
    session:
      id: 6
      title: "Nexus in Action: Integrated Increment & Sprint Review"
      duration: 120
      content: |
        Continues the Nexus simulation through the end of the Sprint. This session emphasizes producing an integrated **Increment** and inspecting it at scale. Students learn how multiple teams collaborate throughout the Sprint to build a single, integrated product increment and ensure it meets the Nexus-wide Definition of Done. The **Nexus Sprint Review** is covered as a joint event where all teams and stakeholders review the integrated increment together to gather feedback. Techniques for running effective large-scale Sprint Reviews (e.g., coordinated demos across teams) are discussed. The session also details the **Nexus Sprint Retrospective**, which has three parts (overall Nexus Retrospective, individual team retrospectives, and a final Nexus Retrospective) to identify improvements both across the Nexus and within each team. Through the case study, students plan a combined Sprint Review for Surge Pricing (showcasing a unified product increment) and practice conducting a Nexus Retrospective to uncover cross-team improvements (such as better integration testing processes).
      learningResources:
        - title: "Resurrecting the Scrum of Scrums (Scaling Daily Sync)"
          link: "https://www.scrum.org/resources/blog/resurrecting-much-maligned-scrum-scrums"
          duration: 5
          type: reading
          weight: 1
        - title: "The Definition of Done vs. Acceptance Criteria"
          link: "https://www.scrum.org/resources/definition-done-vs-acceptance-criteria"
          duration: 4
          type: video
          weight: 2
      assignment:
        title: "Plan a Nexus Sprint Review"
        content: |
          Outline how you would conduct a Sprint Review for a Nexus delivering a single integrated increment. Define what would be demonstrated and who should be involved to get meaningful feedback on the overall product.
        examples: |
          - Describe a plan for the Surge Pricing Nexus Sprint Review: *"Demonstrate a working booking transaction with surge pricing applied. Team A presents the pricing engine functionality, Team B shows the updated user interface using that engine – all in one combined demo to stakeholders from sales, customer support, and IT."* Ensure the focus is on the **Integrated Increment** rather than team-by-team reviews.
          - Identify key stakeholders from multiple business areas and how you would engage them in the review. *For instance, involve airline revenue managers to validate the pricing algorithm output and mobile app users to give feedback on the new UI display.* Explain how their input will be collected for the Nexus to adapt in the next Sprint.

  - type: "session"
    session:
      id: 7
      title: "Managing the Nexus: Transparency, Metrics & Scaling Practices"
      duration: 120
      content: |
        Addresses how to effectively manage and sustain a Nexus over time. Students explore ways to maintain transparency and oversight when many teams are working together. The session introduces metrics and tools (often drawing on **Evidence-Based Management** principles) to track progress and value in a scaled environment – for example, measuring integrated velocity, release frequency, defect trends, and other Key Value Areas (Current Value, Time-to-Market, Ability to Innovate, Unrealized Value). Participants discuss how to visualize Nexus work (using information radiators like integrated burndown charts or dependency boards) and how to detect when a Nexus is not improving. Common scaling **challenges** are revisited (e.g., communication bottlenecks, technical debt across teams, managing changing priorities across a large group) along with proven Nexus practices to address them (like frequent cross-team refinement, continuous integration tooling, and coaching techniques). By relating these concepts to the Surge Pricing case, learners consider what metrics might indicate the Nexus' success (e.g., faster pricing updates deployment) and share techniques to proactively manage a Nexus for the long run.
      learningResources:
        - title: "10 Barriers to Scaling Scrum (Webinar Recap)"
          link: "https://www.scrum.org/resources/10-barriers-scaling-scrum-how-break-them-down"
          duration: 60
          type: video
          weight: 1
        - title: "How to Measure Value with EBM (Evidence-Based Management)"
          link: "https://www.scrum.org/resources/how-measure-value-evidence-based-management"
          duration: 7
          type: reading
          weight: 2
      assignment:
        title: "Nexus Metrics Dashboard"
        content: |
          Propose a simple dashboard or set of metrics to monitor the health and progress of a Nexus over time. Think about what information would help the Nexus (and stakeholders) see how well value is being delivered and where improvements are needed.
        examples: |
          - List 3–5 metrics under categories like **Product Value** and **Delivery Efficiency**. For example: *"Current Customer Value: customer satisfaction score for the integrated product (CV), Time-to-Market: average cycle time from idea to release (T2M), Quality: number of integration defects per Sprint."* Explain why each metric matters for a Nexus.
          - Sketch a dashboard concept: *"Include a release burn-up for the entire Nexus, a bar chart of features delivered vs. planned across all teams, and a line graph of end-to-end system uptime or performance over the last few Sprints."* Ensure these metrics encourage appropriate behavior (collaboration and quality over just speed).

  - type: "session"
    session:
      id: 8
      title: "Nexus+ and Course Wrap-up"
      duration: 120
      content: |
        Explores scaling beyond a single Nexus and concludes the course. The concept of **Nexus+** is introduced for situations with more than 9 teams (i.e., multiple Nexuses working together). Students learn the guiding principles for coordinating large-scale development with many teams, and discuss when it might be necessary to **de-scale** (simplify) instead of adding more layers. The course synthesizes all topics, tying back to how *scaled Scrum remains Scrum* even at very large scale. The Surge Pricing case study is wrapped up with a discussion on outcomes and what a full Nexus implementation would look like post-class. Finally, students prepare for the **SPS certification assessment** and identify next steps in their learning journey. The session includes a retrospective on the course itself and ensures that each participant has an action plan to apply their new knowledge in their organization.
      learningResources:
        - title: "Scaling Beyond Nexus (Nexus+ Overview)"
          link: "https://www.scrum.org/resources/scaling-scrum"
          duration: 5
          type: reading
          weight: 1
        - title: "Scrum.org Nexus Open Assessment (Practice Exam)"
          link: "https://www.scrum.org/open-assessments/nexus-open"
          duration: 30
          type: assessment
          weight: 2
      assignment:
        title: "Personal Scaling Action Plan"
        content: |
          Formulate a concrete action plan for applying what you've learned to your real-life context. Identify two or more changes or experiments you will try in your team or organization to improve scaling with Nexus practices.
        examples: |
          - *"Schedule a meeting with leadership to present a summary of Nexus and propose a pilot with two teams on Project X, focusing on establishing one Product Backlog and a Nexus Integration Team."*
          - *"Initiate a bi-weekly cross-team Scrum Master sync (a scaled retrospective forum) to start tackling dependencies and sharing improvements across teams."* Outline a timeline and desired outcomes for each action so you can measure success after the course.
