The Nexus framework was created by Ken Schwaber,co-creator of the Scrum framework, and was
released by his association,Scrum.org, along with a body of knowledge, the Nexus Guide.
Nexus is grounded on the Scrum framework and uses an iterative and step-by-step approach to spanning
software and product development. Nexus augments Scrum minimally with one substitute part and some
distended events and artifacts. It preserves Scrum. As Ken describes it, “ Nexus is the exoskeleton of
Scrum. ”
A Nexus consists of 3- 9 Scrum Teams working out on a single Product Backlog to make an Integrated
Increment that meets a design. Nexus has a single Product Owner who manages a single product.
Definition of Nexus
According to Nexus Guide:
Nexus is a framework consisting of roles, events, artifacts, and rules that bind and weave together the
work of approximately three to nine Scrum Teams working on a single Product Backlog to build an
Integrated Increment that meets a goal.
Common Scaling challenges solved by Nexus
- Reducing cross-team dependencies.
- Preserving team self-management and transparency.
- Ensuring accountability.
Reasons of dependencies
Nexus helps to make transparent reliances. These reliances are frequently caused by mismatched communed to:
- Product Structure: The difficulty of producing an integrated product release will be strongly influenced by how well-defined the various issues are in the product.
- Communication Structure: The effectiveness of team communication within and between teams impacts how quickly work is done; feedback and communication delays slow the workflow.
Nexus Framework
Nexus improves on Scrum’s core components in order to address the problems of dependency and teamwork that arise in cross-team work.
In the following ways, Nexus expands Scrum:
- Accountabilities: A valuable, practical Integrated Increment is delivered by the Nexus at least once per Sprint, thanks to the efforts of the Nexus Integration Team. The Product Owner, a Scrum Master, and Nexus Integration Team Members make up the Nexus Integration Team.
- Events: Events are added to, positioned around, or take the place of regular Scrum events in order to enhance them. They benefit each team as well as the collective effort of all the Scrum Teams in the Nexus when updated. The goal of the Sprint is a Nexus Sprint Goal.
- Artifacts: The Product Backlog is the same across all Scrum Teams. As the Product Backlog items are polished and prepared, it becomes clearer which team will likely complete the work within a Sprint. There is a Nexus Sprint Backlog to help with transparency during the Sprint. The whole integrated work that has now been finished by a Nexus is represented by the Integrated Increment.
Accountabilities in Nexus
Scrum Teams that collaborate on a product goal form a nexus. The Developers, the Product Owner, and the Scrum Master are three distinct sets of accountabilities that are defined by the Scrum framework for a Scrum Team. The Scrum Guide specifies these accountability requirements. The Nexus Integration Team is a new form of accountability in Nexus.
Nexus Integration Team
A completed Integrated Increment (the cumulative work finished by a Nexus) must be delivered at least once per Sprint, according to the Nexus Integration Team’s responsibility. It offers the concentration necessary for numerous Scrum Teams to collaborate in order to produce worthwhile, practical Increments, as per Scrum’s guidelines.
The Nexus Integration Team is made up of the Product Owner, a Scrum Master, and the necessary members of the Scrum Teams. The members who are qualified to assist Nexus at any moment with its problems should be considered appropriate members. The Nexus Integration Team’s makeup may alter over time to meet Nexus’s evolving needs. The Nexus Integration Team frequently engages in mentoring, consulting, and bringing attention to dependencies and cross-team difficulties.
The Nexus Integration Team consists of:
- The Product Owner: A Product Backlog is a foundation upon which a Nexus operates, and according to Scrum, each Product Backlog has a single Product Owner who has the last word over its contents. The Product Owner is in charge of optimizing the worth of the final product as well as the work completed and integrated by the Scrum Teams in a Nexus. Effective management of the Product Backlog falls under the purview of the Product Owner as well. Different organizations, Nexuses, Scrum Teams, and people may approach this in very different ways.
- A Scrum Masters: In the Nexus Integration Team, the Scrum Master is responsible for ensuring that the Nexus framework is understood and applied as specified in the Nexus Guide. One or more of the Scrum Teams in the Nexus may also have this Scrum Master as their Scrum Master.
- One or more Nexus Integration Team Members: Scrum Team members that assist the Scrum Teams in adopting tools and techniques that support the Scrum Teams’ capacity to provide a valuable and practical Integrated Increment that frequently satisfies the Definition of Done regularly make up the Nexus Integration Team.
The Nexus Integration Team is in charge of mentoring and directing the Scrum Teams in order to help them learn, use, and acquire processes and tools that will help them generate valuable, useful increments.
Note: Individual Scrum Team membership is subordinate to Nexus Integration Team membership.
Nexus Process Flow
Following is the Nexus process flow which the Nexus Integration Team should use to deliver a potentially releasable integrated increment by the end of the sprint.
1) Refined the Product Backlog: It is necessary to break down the product backlog in order to identify dependencies and eliminate or reduce them. Product Backlog items are cut into functionally sliced-up chunks, and the team most likely to complete the job should be determined.
2) Nexus Sprint Planning: Each Scrum Team’s appropriate representative attends a meeting to discuss and review the finalized Product Backlog. For each team, they choose things from the Product Backlog. Then, each Scrum Team develops its own Sprint plan, collaborating with other teams as necessary. The result is a single Nexus Sprint Backlog, one Sprint Backlog for each Scrum Team, and a set of Sprint Goals that are in line with the overall Nexus Sprint Goal. The work of every item on the Scrum Team’s chosen Product Backlog and its dependencies are clear thanks to the Nexus Sprint Backlog.
3) Development Work: Every team usually incorporates its work into a common setting. that can be examined to see if the integration was successful.
4) Nexus Daily Scrum: Every day, the appropriate representatives from each Development Team gather to discuss any integration problems. Upon identification, this data is returned to each Scrum Team’s daily scrum. Then, using the results of the Nexus Daily Scrum, Scrum Teams utilize their Daily Scrum to develop a plan for the day, making sure to address the integration concerns that were brought up.
5) Nexus Sprint Review: At the conclusion of the Sprint, the Nexus Sprint Review is held to offer a Nexus’s Integrated Increment over a Sprint is being evaluated. Stakeholders from each separate Scrum Team gather to discuss the Integrated Increment. The Product Backlog may need to be modified.
6) Nexus Sprint Retrospective: Each Scrum Team’s appropriate representative gathers to Identify recurring problems. Following that, each Scrum Team conducts its own Sprint Retrospective. In order to give bottom-up intelligence, the appropriate representatives from each team reassemble to discuss any actions that may be required in light of common challenges.
Nexus Events
The events specified by Scrum are enhanced or expanded by Nexus. The length of the related events in the Scrum Guidance serves as a guide for the length of Nexus events. In addition to their accompanying Scrum events, they are time-boxed. Below are the Nexus Events consists of:
1) The Sprint: A Nexus sprint is equivalent to a Scrum sprint. A single Integrated Increment is produced by all of the Scrum Teams in a Nexus.
2) Cross-Team Refinement: Cross-team dependencies within a Nexus are decreased or removed through cross-team refinement of the product backlog. The Product Backlog needs to be broken down so that dependencies are clear, recognized by different teams, and eliminated or reduced. Product Backlog items are broken down into actionable work that can be completed by a single Scrum Team during a Sprint at various levels, starting with very large and ambiguous requests.
Scalable cross-team product backlog refinement accomplishes two objectives:
- It aids the Scrum Teams in making predictions about which team will complete which Product Backlog items.
- It reveals dependencies between such teams.
3) Nexus Sprint Planning: Nexus Sprint Planning’s goal is to organize all Scrum Teams within Nexus’s operations for a single Sprint. To plan the Sprint, the Product Owner meets with the appropriate members from each Scrum Team.
The outcomes of the Nexus Sprint Planning meeting are:
- A Nexus Sprint Goal that is consistent with the Product Goal and outlines the objective that Nexus will pursue during the Sprint.
- Each Scrum Team’s Sprint Goal should be in line with the Nexus Sprint Goal.
- A single Nexus Sprint Backlog that encapsulates all of the work being done by the Nexus to achieve the Nexus Sprint Goal and makes cross-team interdependence clear.
- A Sprint Backlog that details the tasks each Scrum Team will accomplish to advance the Nexus Sprint Goal
4) Nexus Daily Scrum: The goal of the Nexus Daily Scrum is to pinpoint integration problems and monitor advancement toward the Nexus Sprint Goal. Appropriate Scrum Team representatives attend the Nexus Daily Scrum to evaluate the integrated Increment’s current state, identify integration problems, and find any recently discovered cross-team dependencies or implications. In order to solve the integration issues brought up during the Nexus Daily Scrum, each Scrum Team’s Daily Scrum complements the Nexus Daily Scrum by formulating goals for the day.
5) Nexus Sprint Review: The Nexus Sprint Review is held at the conclusion of the Sprint to gather input on the completed Integrated Increment that the Nexus has constructed throughout the Sprint and to determine future adjustments.
6) Nexus Sprint Retrospective: The goal of the Nexus Sprint Retrospective is to develop strategies for raising quality and efficacy throughout the Nexus. The Nexus evaluates the performance of the most recent Sprint in terms of people, teams, interactions, procedures, tools, and its definition of doneness. The Scrum Teams’ Sprint Retrospectives complement the Nexus Sprint Retrospective by utilizing bottom-up intelligence to concentrate on problems that affect the Nexus as a whole, in addition to individual team improvements.
Nexus Artifacts and Commitments
According to the Scrum Guide, artifacts are created to maximize transparency and reflect effort or value. In order to establish transparency across all artifacts and to guarantee that everyone is aware of the status of the Integrated Increment, the Nexus Integration Team collaborates with the Scrum Teams inside a Nexus.
Each of the following artifacts that Nexus adds to Scrum contains a commitment, as shown below. For Nexus and its stakeholders, these pledges serve to support empiricism and the Scrum value.
1) Product Backlog: For the entire Nexus and all of its Scrum Teams, there is only one Product Backlog that lists all of the improvements that must be made to the product. At scale, it is necessary to comprehend the Product Backlog at a level where dependencies can be identified and reduced. The Product Backlog’s availability, ordering, and content are all under the Product Owner’s control.
Commitment: Product Goal
The Product Goal represents the commitment to the Product Backlog. The long-term objective of Nexus is the Product Goal, which outlines the status of the product in the future.
2) Nexus Sprint Backlog: The elements from the sprint backlogs of the separate Scrum Teams’ Nexus Sprint Goals and Product Backlogs are combined to form a Nexus Sprint Backlog. During the Sprint, it is utilized to draw attention to dependencies and the workflow. As new information becomes available, the Nexus Sprint Backlog is updated. The Nexus should be able to check their progress in the Nexus Daily Scrum thanks to its sufficient level of detail.
Commitment: Nexus Sprint Goal
The Nexus Sprint Goal is the commitment for the Nexus Sprint Backlog. The Nexus has just one goal, which is the Sprint Goal. The work and Sprint Goals of all the Scrum Teams within the Nexus are combined to create it. Encouraging the Scrum Teams to collaborate rather than work on separate efforts, generates coherence and focus for the Nexus for the Sprint. The Nexus Sprint Planning event results in the creation of the Nexus Sprint Goal, which is then put into the Nexus Sprint Backlog. Scrum Teams keep the Nexus Sprint Goal in mind while they work during the Sprint. At the Nexus Sprint Review, the Nexus should show off the valuable and practical functionality that is implemented to achieve the Nexus Sprint Goal.
3) Integrated Increment: The total integrated work that has currently been finished by a Nexus in support of the Product Goal is represented by the Integrated Increment. The Integrated Increment is examined at the Nexus Sprint Review, though it could be given to stakeholders beforehand. It is required that the Integrated Increment adheres to the Definition of Done.
Commitment: Definition of Done
The Definition of Done, which describes the status of the integrated work when it satisfies the standards and measurements required for the product, serves as the commitment for the Integrated Increment. Only when it is useful, integrated, and used is the increment made. The Definition of Done for the Integrated Increment created each Sprint must be provided by the Nexus Integration Team. Within the Nexus, this Definition of Done must be established and followed by all Scrum Teams. To achieve this level, individual Scrum Teams self-manage. Within their own teams, they may opt to use a stricter definition of done, but they are not allowed to use less stringent standards than those set for the Integrated Increment.
If you want to learn more about Nexus Framework you can refer to Nexus Guide.
If you want to know how to create sprints in Jira you can refer to this blog.
