Product LeadersMasterclass

Scaled Professional Scrum with Nexus (SPS) Certification Course

Learn to scale Scrum with the Nexus Framework, tackle cross-team challenges, and prepare for SPS certification through hands-on workshops and collaborative exercises.

MasterclassScrum.orgTraditional (Full Day) · Traditional (Half Day) · Immersive

What changes for your team

  • Make multiple Scrum teams move as one
  • Turn cross-team blockers into flow
  • Certification readiness with real application

Immersive training pays back differently to a two-day course. Sessions spread across several weeks mean each idea is applied in your real work before the next one lands — so capability builds instead of fading under a backlog. Why immersive produces better returns →  ·  Other formats available in the panel above.

Course Code: SPS

Overview

A hands-on, activity-based course designed to equip professionals with practical skills for scaling Scrum using the Nexus Framework, addressing cross-team challenges, and preparing for the Scaled Professional Scrum (SPS) certification.

Target Audience

  • Product Owners
  • Product Managers
  • Scrum Masters
  • Lean Agile Practitioners
  • Scrum Teams
  • Development Leads and Managers
  • Anyone involved in managing or participating in scaled Scrum product development

Learning Outcomes

  • Understand that scaled Scrum is still Scrum
  • Gain an introduction to the Nexus Framework
  • Learn new roles, artifacts, and events in Nexus
  • Organize teams and work for large-scale development
  • Manage the Nexus and Nexus+
  • Address common challenges in scaling Scrum
  • Apply practices to efficiently build integrated software products
  • Experience organizing several teams working on the same product
  • Optimize team productivity
  • Identify, minimize, and remove dependencies

Course Topics

  • Scaling Scrum and organizing teams
  • Team selection and organizing work
  • Nexus in action
  • Managing the Nexus
  • Overcoming cross-team dependencies and collaboration challenges
  • Practices for launching, structuring, and managing large Agile projects

Certification

  • Includes one free attempt at the Scaled Professional Scrum (SPS) certification exam
  • Second attempt provided if the first is taken within 14 days and unsuccessful

Frequently Asked Questions

Scaled Professional Scrum with Nexus (SPS) is designed for experienced Scrum professionals: Scrum Masters, Product Owners, team members, Agile coaches, and department managers involved in scaling Scrum across multiple teams. It is not suitable for those with little to no prior Scrum experience.

SPS includes one free attempt at the Scaled Professional Scrum (SPS) certification exam; if you take your first attempt within 14 days and don’t pass, you’re granted a second try at no additional cost.

You’ll tackle cross-team dependencies, challenges in organising multiple Scrum teams, transparency issues, and approaches for delivering value at scale—all based on typical obstacles organisations face when scaling Scrum.

You should have strong, hands-on Scrum experience in roles like Scrum Master, Product Owner, or team member before attending SPS; it’s not suitable for those unfamiliar with Scrum.

The SPS certification from Scrum.org is globally recognised and valued by employers and the Agile community as evidence of your understanding of scaling Scrum with Nexus.

Syllabus

Here is exactly what your team will cover, and how we deliver it. Every format teaches the same modules; what changes is how the time is spread and what happens between sessions:

Immersive RecommendedTraditional (Full Day)Traditional (Half Day)
Sessions 8 sessions 2 days 4 half-days
Each session 4h: 2h reflect + 2h learn 8h incl. breaks and lunch 4h incl. breaks
Total time with an expert 32h 16h 16h
New concept and practice
incl. breaks		 16h 16h 16h
Facilitated reflection
what happened when you tried it		 16h — —
~Expert time per topic
breaks removed		 ~3h20
1h40 reflect + 1h40 learn		 ~1h30 ~1h40
Time to apply between sessions 1–2 working weeks (≈36–72h) Overnight Half a working day (≈4h)

Each immersive session follows a learning cycle: reflect on what happened when you applied the last concept, learn the next one and practise it, then take it back to work as an outcome-based assignment. It is designed for triple-loop learning, so participants do not just change what they do; they question why they do it and how they see their organisation.

Need more support? The immersive experience can be combined with additional coaching, consulting or mentoring to create a Mentor Program for your team.

Choose a format above to see how the modules group into sessions.

Before You Start

Complete the pre-work below before your first session so you arrive ready to participate.
  • Resource Pre-Course Assessment
  • Resource Review Scrum Guide

Session 1 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Scaling Scrum Fundamentals & Case Study Kickoff

Module 1

Learn a new concept

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.

Outcome-based assignment: Identify Scaling Challenges · Immersive only

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.
For example, you might:
  • 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.”
→ Reflected on at the start of Module 2: Nexus Framework Deep Dive

Session 2 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Nexus Framework Deep Dive

Module 2

Facilitated reflection: Identify Scaling Challenges · Immersive only

Facilitated reflection: Identify Scaling Challenges

Learn a new concept

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.

Outcome-based assignment: Nexus Framework Reflection · Immersive only

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.
For example, you might:
  • 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.”
→ Reflected on at the start of Module 3: Organizing Teams & Nexus Integration Team

Session 3 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Organizing Teams & Nexus Integration Team

Module 3

Facilitated reflection: Nexus Framework Reflection · Immersive only

Facilitated reflection: Nexus Framework Reflection

Learn a new concept

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.

Outcome-based assignment: Design a Scaled Team Structure · Immersive only

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.
For example, you might:
  • 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.”
→ Reflected on at the start of Module 4: Organizing the Work & Managing Dependencies

Session 4 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Organizing the Work & Managing Dependencies

Module 4

Facilitated reflection: Design a Scaled Team Structure · Immersive only

Facilitated reflection: Design a Scaled Team Structure

Learn a new concept

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.

Outcome-based assignment: Shared Definition of Done Draft · Immersive only

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.
For example, you might:
  • 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.
→ Reflected on at the start of Module 5: Nexus in Action: Sprint Planning & Daily Coordination

Session 5 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Nexus in Action: Sprint Planning & Daily Coordination

Module 5

Facilitated reflection: Shared Definition of Done Draft · Immersive only

Facilitated reflection: Shared Definition of Done Draft

Learn a new concept

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.

Outcome-based assignment: Scaled Sprint Goal & Plan · Immersive only

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.
For example, you might:
  • 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.”
→ Reflected on at the start of Module 6: Nexus in Action: Integrated Increment & Sprint Review

Session 6 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Nexus in Action: Integrated Increment & Sprint Review

Module 6

Facilitated reflection: Scaled Sprint Goal & Plan · Immersive only

Facilitated reflection: Scaled Sprint Goal & Plan

Learn a new concept

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).

Outcome-based assignment: Plan a Nexus Sprint Review · Immersive only

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.
For example, you might:
  • 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.
→ Reflected on at the start of Module 7: Managing the Nexus: Transparency, Metrics & Scaling Practices

Session 7 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Managing the Nexus: Transparency, Metrics & Scaling Practices

Module 7

Facilitated reflection: Plan a Nexus Sprint Review · Immersive only

Facilitated reflection: Plan a Nexus Sprint Review

Learn a new concept

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.

Outcome-based assignment: Nexus Metrics Dashboard · Immersive only

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.
For example, you might:
  • 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).
→ Reflected on at the start of Module 8: Nexus+ and Course Wrap-up

Session 8 · 2h facilitated reflection + 2h new concept and practice · 10m break each hour

Nexus+ and Course Wrap-up

Module 8

Facilitated reflection: Nexus Metrics Dashboard · Immersive only

Facilitated reflection: Nexus Metrics Dashboard

Learn a new concept

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.

Outcome-based assignment: Personal Scaling Action Plan · Immersive only

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.
For example, you might:
  • “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.
→ Reflected on at the start of Catchup & After

Catchup & After · Immersive only

Catchup & After

Facilitated reflection: Personal Scaling Action Plan

Facilitated reflection: Personal Scaling Action Plan

Two weeks after completion, participants are invited to join a follow-up catch-up session designed to address any remaining questions, ideas, or challenges that have emerged since the training. This session provides an opportunity to reflect on your experiences applying the concepts learned in the course, share insights, and receive additional support.

* Assignments are part of our Immersive Training Programs, encouraging participants to apply their learning practically between sessions for a more hands-on experience.

Ready to bring this to your team?

Private delivery, fixed price, money-back guarantee. Tell us what you need and we'll put together a proposal.

Bring this in-house

If this isn't quite right for where you are

Not sure what would actually move the needle?

Most organisations don't need a course catalogue. They need a diagnosis. Tell me what's not working, who is involved, and what you've already tried. I'll tell you honestly whether training will help, and if so, what.

Start a conversation Browse programmes