Nexus Definition
- A Nexus is a group of approximately three to nine Scrum Teams that work together to deliver a single product; it is a connection between people and things.
- A Nexus has a single Product Owner who manages a single Product Backlog from which the Scrum Teams work.
- The Nexus framework defines the Accountabilities, Events, and Artifacts that bind and weave together the work of the Scrum Teams in a Nexus.
- Nexus builds upon Scrum’s foundation, and its parts will be familiar to those who have used Scrum.
- It minimally extends the Scrum framework only where absolutely necessary to enable multiple teams to work from a single Product Backlog to build an Integrated Increment that meets a goal.
Nexus Accountabilities
- A Nexus consists of Scrum Teams that work together toward a Product Goal.
- The Scrum framework defines three specific sets of accountabilities within a Scrum Team : the Developers, the Product Owner, and the Scrum Master.
- These accountabilities are prescribed in the Scrum guide.
- In Nexus, an additional accountability is introduced, the Nexus Integration Team.
Nexus Integration Team
- The Nexus Integration Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint.
- It provides the focus that makes possible the accountability of multiple Scrum Teams to come together to create valuable, useful Increments, as prescribed in Scrum.
- While Scrum Teams address integration issues within the Nexus, the Nexus Integration Team provides a focal point of integration for the Nexus.
- Integration includes addressing technical and non-technical cross-functional team constraints that may impede a Nexus’ ability to deliver a constantly Integrated Increment.
- It should use bottom-up intelligence from within the Nexus to achieve resolution.
- The Product Owner, the Scrum Master, and the appropriate members from the Scrum Teams belong to the Nexus Integration Team.
- Appropriate members are the people with the necessary skills and knowledge to help resolve the issues the Nexus faces at any point in time.
- Composition of the Nexus Integration Team may change over time to reflect the current needs of a Nexus.
- Common activities the Nexus Integration Team might perform include coaching, consulting, and highlighting awareness of dependencies and cross-team issues.
- The Nexus Integration Team consists of:
- The Product Owner :
- A Nexus works off a single Product Backlog, and as described in Scrum, a Product Backlog has a single Product Owner who has the final say on its contents.
- The Product Owner is accountable for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus.
- The Product Owner is also accountable for effective Product Backlog management.
- How this is done may vary widely across organizations, Nexuses, Scrum Teams, and individuals.
- A Scrum Master :
- The Scrum Master in the Nexus Integration Team is accountable for ensuring the Nexus framework is understood and enacted as described in the Nexus Guide.
- This Scrum Master may also be a Scrum Master in one or more of the Scrum Teams in the Nexus.
- The Scrum Master in the Nexus Integration Team is accountable for ensuring the Nexus framework is understood and enacted as described in the Nexus Guide.
- One or more Nexus Integration Team Members:
- The Nexus Integration Team often consists of Scrum Teams members who help the Scrum Teams to adopt tools and practices that contribute to the Scrum Teams’ ability to deliver a valuable and useful Integrated Increment that frequently meets the Definition of Done (DoD).
- The Product Owner :
- The Nexus Integration Team is responsible for coaching and guiding the Scrum Teams to acquire, implement, and learn practices and tools that improve their ability to produce a valuable, useful Increment.
- Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership.
- As long as their Nexus Integration Team responsibility is satisfied, they can work as team members of their respective Scrum Teams.
- This preference helps ensure that the work to resolve issues affecting multiple teams has priority.