Notes and summary of the Nexus Guide by Ken Schwaber made in preparation for the SPS™ certification exam.
Useful links and resources for SPS™ exam preparation
- Nexus Guide: https://www.scrum.org/resources/online-nexus-guide
- Nexus Open Assessment: https://www.scrum.org/open-assessments/nexus-open
- MLapshin's SPS™ Preparation Quiz: https://mlapshin.com/index.php/scrum-quizzes/scaled-scrum-quiz/
- Thescrummaster.co.uk Preparation Quiz: https://www.thescrummaster.co.uk/sps-practice-assessment/
- Ken Schwaber's intro to Scaled Scrum: https://www.youtube.com/watch?v=xm4X7Hv_GOs
To define a framework to develop scaled product and software delivery initiatives using Scrum as its building block. Developed by Ken Schwaber and Scrum.org
Framework consisting of:
✅ Roles
✅ Events
✅ Artifacts
✅ Rules
1 single product backlog 📜 🔗 👥 by 3-9 teams to build an integrated increment
Integration and coordination of work to deliver a done increment by several teams
Dependencies arise between multiple teams, and they relate to:
- 📃 Requirements (Overlapping and affecting each other)
- 💡 Domain Knowledge (The teams have the right knowledge to do the job)
- 💻 Software & Test artifacts
📉 dependencies == 📈 productivity
Consistent with Scrum, but it pays more attention
Scrum Roles + the Nexus Integration Team (NIT)
Scrum Artifacts + Nexus Sprint Backlog
Appends all the Scrum Events minus Sprint Review ❌ (replaced by Nexus Sprint Review)
A nexus consists of multiple cross-functional teams working together to deliver an integrated increment at least a the end of each sprint. Teams self-organize to pick up work based on dependencies.
✏️ Nexus Refinement: decompose and identify dependencies
🔖 Nexus Planning: Discuss & select PBL for each team, then they plan their own sprint and realign on an integrated goal and sprint backlog on top of their own
🔁 Nexus Daily Scrum: Appropriate representatives meet to identify integration issues and dependencies, then they take this info back to their own daily scrums
✔️ Nexus Sprint Review: Integrated demonstration to stakeholders with adjustment & feedback gathering
⏪ Nexus Retrospective: Appropriate representatives meet to discuss cross-team issues, then normal sprint retro for each team, then appropriate representatives meet again to re-align and plan the follow up.
Roles, events & artifacts inherit the purpose from the corresponding Scrum roles
A nexus consists of:
- 1 NIT
- 3-9 teams
✅ Accountable for ensuring a Done Integrated increment is produced at least once/sprint. It consists of:
-
🎩 THE PO:
- ☝️ The single PO for the whole Nexus
- 💶 Maximizes the value of the product
- 📊 Manages BL
-
👂 A SM:
- ☑️ Ensures the Nexus framework is understood and enacted
- 🔛 May be SM in 1 or several scrum teams
-
👥 1 or more NIT members:
- 💻 Professionals skilled in the use of tools, practices and field of Sys Eng.
- 🔛 Often they are also part of the individual scrum teams
- ☝️ Nexus work takes priority over scrum team work
- 🔀 Membership may change over time
- 🔦 Coaches, consults and highlights awareness of cross-team issues
- ⬆️ They use bottom-up intelligence to achieve resolution
🕐 Duration is guided by the duration of the corresponding Scrum event. 👀 Inspection and adaption will help with time-boxing them.
- 📌 Mandatory
- 👍 Helps identifying & forecasting which team will deliver which PBI
- 🔀 Helps identifying the dependencies
- 🔄 Continues until PBIs are independent enough
- 🤷♂️ Number, Frequency and attendance depends on dependencies and PBL uncertainty
- 🔁 It's continuous as necessary
- 🚦 Coordinates activities of all scrum teams for a single sprint
- 🚩 PBL should be refined with dependencies id'd, remov'd or minimiz'd prior
- 2 parts:
- ☝️ Appropriate reps from each scrum team meet to validate and decide what each team will do & PO discusses the Nexus Sprint Goal (purpose that will be achieved by all the teams)
- ✌️ Individual Scrum Teams Sprint Planning
- 🏁 Finishes when all individual teams Sprint Plannings have finished
- ➕ Generates a Nexus Sprint Backlog with the combination of the all the individual sprint backlogs
⤴️ Dependencies are transparent on the Nexus Sprint Backlog
Appropriate representatives of individual dev teams meet to inspect current state of integrated increment and discover new cross team issues. Should discuss:
- ♻️ Was the previous day’s work successfully integrated? 🤷♂️ If not, why not?
- 💣 What new dependencies or impacts have been identified?
- 💁 What information needs to be shared across teams in the Nexus?
‼️ Replaces Sprint Review- 🏁 Held at the end of the sprint
- ☑️ Review the integrated increment with stakeholders to gather feedback and adjust PBL
- 🆕 New techniques might be necessary to maximize stakeholder feedback
- 📜 Results in a revised PBL
-
🔄 Occurs after Nexus Sprint Review and before Nexus Sprint Planning.
-
Consists of 3 parts:
- 🔍 Appropriate reps from each team meet & id issues that impacted more than 1 team. Makes shared issues transparent
- 👀 Each team holds their own Sprint Retrospective, using the input from part 1
- ✏️ Appropriate reps from each team meet to realign and agree on tracking/visualizing actions.
-
Should answer / address:
- 🚧 Was any work left undone? Did the Nexus generate technical debt?
- ✅ Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?
- ✅ Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?
- Why?
- How can tech debt be undone?
- How can this be avoided in the future?
Provide transparency & opportunities for I&A
- 📜 1 PBL to rule them all.
- 🎩 PO is accountable for it
- ⏩ PBIs are "ready" for Nexus Sprint Planning when teams can select items to be done with no or minimal dependencies
- ➕ Composite of PBIs from Sprint Backlogs of the Scrum Teams.
- 🔆 Highlights dependencies and flow of work during sprint
- 🔄 Updated at least once/day during Nexus Daily Scrum
- ➕ Represents current sum of all integrated work completed by a Nexus
- 👍 Must be usable and potentially releasable (meets DoD)
- 🔍 Is inspected at Nexus Sprint Review
The NIT works with the Scrum Teams to ensure transparency is apparent across all artifacts. Software must be developed so that dependencies are detected and resolved before death by tech debt
- ✅ NIT defines the DoD for the Nexus
- 🔛 All teams adhere to DoD
- 🛃 Individual teams may choose their own DoD so long as it complies with the Nexus'
🚫 Nexus is immutable. Can be partially implemented, but the result: ❌ Nexus