Scaled Professional Scrum with Nexus Practices

Scrum is a framework from which process evolves. A Scrum Team or organization will build their process by assembling the proper practices that they feel will help them succeed with Scrum at the heart.

Nexus extends Scrum to guide multiple Scrum Teams on how they need to work together to deliver working product in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies. In the Scaled Professional Scrum with Nexus course, students learn about many of the practices available to help their teams better scale. The intent of the below chart is to help readers understand those practices and find ways to learn more.

Forming a Nexus - Organizing Teams
Forming a Nexus - Organizing Work
Running a Nexus
Managing a Nexus

Forming a Nexus - Organizing Teams

Practice	Summary	Why Use?
Start with a small team, then grow	A team scaling technique that starts with a small team. As this team grows, the team splits and members move to start new teams.	To help one team to become high-performing first, then help another, then help another. Avoids the problem of scaling mediocre team performance.
Internship Model	A team scaling technique that preserves the original team. Add new people to a high performance team, then new people move to start their own teams.	To share knowledge across teams and to instil a shared culture across teams when scaling the number of teams.
Feature Teams	A team formation approach that consists of a cross-functional team that is able to pull, deliver, and support an end-to-end feature.	To give teams deeper insight into customer needs and to reduce waste and wait-time by reducing hand-offs of work to people outside the team.
Microservices	An architectural style that organizes the architecture of applications around a set of narrowly-focused, independently deployable services.	To improve the modularity of the code, which improves its maintainability, making it easier to change different parts of the code independently from other parts.
UI Drives Feature Areas	A team formation technique that uses the User Interface to identify areas of high cohesion and low coupling, then form teams around these areas.	To reduce cross-team dependencies, based on an assumption that different parts of the UI serve different needs and can be decoupled from other parts.
Persona Teams	A team formation approach where teams form around personas, which are fictionalized abstract descriptions of types of users of the application.	To give teams deeper insight into the users of an application, which can help them feel more connected to the user, which can help them build better solutions.
Feature Set Teams	A team formation approach where teams form around customer-facing product areas, which are also known as value areas.	To scale feature teams by focusing on a consistent customer experience in a domain area.
Team Self-Selection	A team formation technique where team members choose which team they join based on their interests, their constraints, and the needs of the team.	To increase the sense of team identification and reduce team conflicts by empowering people to choose what they work on and who they work with.

Forming a Nexus - Organizing Work

Practice	Summary	Why Use?
Impact Mapping	A planning technique that uses a visual map to help communicate and connect business goals, personas, outcomes, impacts, and Product Backlog Items (PBI)	To understand the connection between PBIs and the product and business goals they satisfy.
User Story Mapping	A planning technique that helps teams to decompose user stories into manageable chunks of work by visualizing user stories along two independent dimensions.	To provide a structured way to refine PBIs to flesh out an initial usable version of a product and then additional functionality.
Track Business-centric items in the Product Backlog	A planning technique that helps teams track business centric items when decomposing the Product Backlog.	To ensure transparency and alignment of work that needs to be done to deliver business value (e.g. development, marketing, support, etc.)
Cross-team Refinement	A Refinement technique used by multiple teams working together on one Product Backlog to reduce or eliminate cross-team Product Backlog Item dependencies.	To improve the flow of work when multiple teams are working together to build a single Product.
Create PBIs as "Thin" as Possible	A planning technique to decompose and split Product Backlog Items along with their acceptance criteria.	To reduce the problem where PBIs are "undone" at the end of a Sprint and to minimize dependencies.

Running a Nexus

Practice	Summary	Why Use?
Visualize your Work	A strategy for making the status of, and progress on, Product Backlog Items visible and therefore transparent.	To communicate and reduce misunderstandings about the status of PBIs.
Nexus Sprint Planning Room Layout	An approach for organizing the teams in Nexus Sprint Planning, including remote teams.	To help improve collaboration during the Nexus Sprint Planning event.
Use the Nexus Sprint Backlog to Manage the Flow of Work	A technique for using the Nexus Sprint Backlog to visualize the status of, and progress on, PBIs, during the Sprint for the Nexus.	To eliminate the need to use other artifacts to make the work transparent by visualizing the sequence and dependencies of the PBIs forecast for the Sprint for the Nexus.
Science Fair/Expo	A set of related techniques that can help to improve the Sprint Review at scale by letting stakeholders see what they want/need to see, on demand, during the Nexus Sprint Review.	To make running large Sprint Reviews more effective and engaging between the Development Teams and stakeholders.
Offline Sprint Review	A set of related techniques that enables teams to better engage with stakeholders when those stakeholders cannot attend the Sprint Review. either in-person or remotely.	To improve the effectiveness of Sprint Reviews when stakeholders can't be present.
Retrospective Board	A set of techniques for making Sprint Retrospective items transparent.	To make sure that Sprint Retrospectives items don't get ignored or forgotten.
Build Experimentation into the Product	A validation approach for evaluating alternatives using a released Product.	To obtain product feedback from users; to better understand whether the Product is meeting user needs.
Build Manual Feedback into the Product	Validation techniques for gathering interest and feedback from a released Product.	To obtain product feedback from users; to better understand whether the Product is meeting user needs.
Build Automated Feedback into the Product	A validation approach for using instrumentation in the application to gather information about usage.	To obtain product feedback from users; to better understand whether the Product is meeting user needs.
Scaled Product Ownership	An approach to scaling Product Ownership by delegating some of the work of Product Ownership while still maintaining Product Owner accountability.	To scale Product Ownership when there's too much work for them to do, and they need help.
Continuous Integration	A development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build and test process, allowing teams to detect problems early.	To discover coding and code integration problems as early as possible, while the code is still fresh in the developer's mind.
Automated Acceptance Testing	An approach for using test automation to verify that requirements are met.	To reduce the level of manual effort that is required to verify that requirements are being met.
Feature Toggles	A technique that enables all work to be integrated regardless of feature readiness	To enable code to be integrated without introducing partially completed work by keeping the code "turned off" until everything is ready for the feature to be used.
Develop for Operations	Techniques that improve the deployability and supportability of applications	To improve the release readiness of a product by making sure that all the work necessary to deploy and support a PBI is completed in the same Sprint.
Track Operations / Infrastructure Work in the Product Backlog	Techniques that improve the deployability and supportability of applications	To improve the release readiness of a product by making sure that all the work necessary to deploy code related to a PBI is completed in the same Sprint.
Teams on Differing Cadences	Techniques for synchronizing the work of multiple teams in a Nexus when their Sprint lengths differ.	To handle the situation in which not all teams in the Nexus cannot get PBIs to "done" at the same rate. Especially relevant in mixed hardware/software products, and products that require some work to be done on legacy code.
Communities of Practice	A technique for forming and supporting groups of people with common interests, for the purpose of sharing learnings and improving skills.	To share information across teams; to improve professionalism across teams.
Track Architecture Work in the Product Backlog	A technique that improves the resiliency and reduce the total lifecycle cost of applications.	To improve the resiliency and reduce the total lifecycle cost of applications.
Facilitate Shared Architecture	A technique for refactoring and sharing components across applications and teams.	To improve the resiliency and reduce the total lifecycle cost of applications.
Internal Open Source (aka "Inner Source")	A technique to enable multiple teams to make changes to the same code at the same time.	To move away from teams owning components to shared component ownership.

Managing a Nexus

Practice	Summary	Why Use?
Product Backlog Treemap	A technique for visualizing the size and completeness of PBIs.	To provide a way of visualizing the size/complexity of PBIs. Also used to make the status of the work transparent.
Feature Burndown	A technique for visualizing the completeness of work at the feature level.	To provide a way to visualize Done and Undone work for a Sprint or for a release.
Health Check	A technique for helping teams assess their own performance.	To provide a lightweight way for teams to self-diagnose challenges so that they can focus on improving the things that will help them most.
World Café	A facilitation technique for knowledge sharing in large groups by breaking them into smaller sub-groups, based on sub-topics, and rotating people through the groups.	To provide a way to share and discuss ideas in a large group environment.
Open Spaces	A facilitation technique for breaking into smaller groups to discuss and focus on topics of interest through self-organization.	To provide a a way to break into sub-groups to focus on ideas or problems when the entire group may not be interested in every topic.
De-scaling	A technique for restoring order to a Nexus that is struggling with scaling problems by reducing the number of teams.	To provide ways to simplify problems arising from having scaled poorly or unnecessarily, especially situations in which the sheer numbers of people involved have become destabilizing.
Scrumble	A technique equivalent of "pulling the andon cord"; stopping work and descaling until stability can be restored to the Nexus.	To deal with a situation in which the Nexus has become incapable of doing useful work, and all work needs to stop until order and coherency can be restored (if possible).
Distributed Teams Travel	An approach for improving cohesiveness and building stronger working relationships with distributed teams.	To improve and increase cross-team collaboration by building personal relationships and creating a shared culture across distributed teams.
Distributed Tooling	A technique for using technology to improve the ability for distributed teams to work together.	To make distributed collaboration more effective through the appropriate use of distributed collaboration technology.