fbpx

The Nexus Framework by Scrum.org for Scaling Scrum

Nexus is a simple framework that implements scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3-9 scrum teams that are working in a common development environment and are focused on producing a combined increment every sprint with minimal dependencies.

Artifacts for Nexus Framework:

  • One Nexus Product Backlog for all teams
  • Individual Sprint Backlog of each Scrum Team
  • Nexus Sprint Backlog is a collection of individual Sprint Backlogs. It is the sprint plan which is helpful in viewing and highlighting dependencies between scrum teams.

The Structure of the Nexus Framework Teams

  • Customary roles of Product Owner, Scrum Master, and self-managing and cross-functional teams. There is a single product owner that leads the complete product. They may be supported by business analysts or system engineers. Scrum masters are responsible for facilitating their respective teams only. Each cross-functional scrum team can have 3-9 members.
  • Nexus Team is constituted of 1-2 members from each scrum team that are responsible for planning the vision and the bigger picture of the overall product and also coordinating all the scrum teams.
  • Nexus Integration Team is responsible for keeping multiple teams technically and successfully integrated. Members of this team are not fixed. These team members may include coaches and trainers which ensure smooth integration and following of the cadence of the work done by the scrum teams. It is the scrum team’s responsibility to integrate their work with each other to produce an integrated increment regularly. If any integration issues arise, one or two team members of each scrum team meet with the integration team to find a solution.

Planning in Nexus

The teams pick out items from the refined Nexus Product Backlog. The backlog can have stories, tasks, business initiatives, epics or any item of any size that suits the teams.

Items in the product backlog are continually refined to minimize or clear away dependencies. New requirements can also be added. It also includes carrying out relevant estimates of story points.

The product owner has the Nexus Product Backlog but if the size of the teams exceeds, then the product owner may delegate some of their tasks to the scrum teams, business analysts, project managers, or other roles.

The sprint planning session has two parts:

In the first part, the Nexus Team conducts a sprint planning session in which they plan the bigger picture of the project. Information and decisions made based are conveyed to the scrum teams. Dependencies are found and sought out. The Nexus Team and the Scrum Teams work in cadence.

Scrum Teams have their individual sprint backlog to work on. During these sprint planning sessions, teams interact and collaborate with each other. Teams align themselves in order to achieve their sprint goals. At the completion of all teams’ sprint backlog planning, Nexus Sprint Backlog is ready.

Development in Nexus

Multiple scrum teams work in a collective working environment to produce an integrated product. Teams fuse their work with each other consistently. The Nexus Integration Team plays a healthy role to ensure that the teams stay harmonized with each other.

Nexus Daily Scrum is when the Nexus Team and the respective scrum team 1-2 members have a scrum session. The purpose of this meeting is to coordinate any challenges and dependencies of the day that all teams should be aware of. The daily scrum is held for each team separately afterward.

A Nexus Sprint Review is held at the end of the sprint in which all the scrum teams meet with the Product Owner and review the integrated increment. Scrum teams do not have their own sprint reviews. There is only one collective sprint review in which the integrated increment is the subject.

Finally, there is a Nexus Sprint Retrospective. The essence of every retrospective is to meet and identify shared challenges. The solutions are discussed by sharing ideas and how they can improve. Afterward, Nexus Team and the scrum teams have their individual retrospectives. Then there is a collective retrospective where solutions are shared with the entire nexus and the scrum teams.

Nexus-Sprint-Retrospective
(Source)

Nexus in a Nutshell

Nexus promotes value instead of expansion. It is a scaling framework that does not say that much about stakeholders. It guides the scrum teams on how to prosper, and resolve coordination issues. It does not mention the restructuring of the whole organization at scale.

One cross-functional Scrum team is the prerequisite of Nexus. Possessing knowledge and having worked in a Scrum environment gives you an edge to work with Nexus. It promotes and ensures transparency, continuous integration, and relentless improvement.

Having a single product and sprint backlog boasts transparency as all the team’s sprint data can be easily visualized. Daily scrums enhance communication and help erase dependencies.

Working in a shared environment where work is constantly being integrated into one final product guarantees continuous integration. Teams use automation to manage any complexities. The Nexus Integration teams give the necessary support and facilitation to the teams in order to keep them in line. Thus eliminating the need for the scrum of scrums meeting that is an essential part of other scaling frameworks. They make sure if the processes are followed and truly work as servant leaders to ensure that the teams flourish.

For architecture, Nexus does not deny the need for an enterprise architect but remains silent on making such a role as part of the integration team. It also emphasizes adapting to any changing requirements using cross-functional teams and eliminate any waste with Lean-Thinking. The teams confirm relentless improvement with activities like the refinement of the product backlog, sprint review, and retrospective.

To improve visibility and transparency, Nexus teams need a tool that fetches real-time data from all the teams and shows a summary at a higher level using Nexus Sprint backlog. Kendis is equipped with customizable boards that can empower Nexus teams to outperform by attaining greater visibility and transparency into Nexus Sprint backlog. Teams are able to create multiple customizable boards that fit in a variable size of the screen seamlessly for big planning and review meetings. Find out more about Kendis here.

For any guidance on Nexus, click on the link below.

 

About Kendis

Digital boards to manage dependencies, multiple teams and program increments for your scaling agile initiatives.

Kendis works on top of JIRA and other agile tools, your teams can keep on working with their existing JIRA boards and program level and above is planned and managed at Kendis.

Try out 10 days free trial or book a demo with our product expert.

 

 


Leave a Reply

Your email address will not be published.Required fields are marked *