Nexus Guide Scaling Scrum

Nexus Guide for Scaling Scrum

Get Started. It's Free
or sign up with your email address
Rocket clouds
Nexus Guide Scaling Scrum by Mind Map: Nexus Guide Scaling Scrum

1. Nexus Sprint Backlog

1.1. Exists to assist with transparency during the sprint it highlight dependencies and the flow of work during the sprint updated daily

1.2. All Scrum Teams mantain their individual Sprint Backlogs

1.3. is the composite of the product backlog items from the sprint backlogs of individual teams

2. is the current sum of all integrated work completed by a Nexus must be usable and potentially releasable

3. DEFINITION

3.1. - Nexus (n): a relatioship or connection between people or things - Is a process framework consisting of roles, events, artifacts and rules that bind together the work of 3 to 9 scrum teams working on a single Product Backlog to meet an Integrated Increment.

4. PURPOSE

4.1. - Is a framework for developing and sustaining scaled product initiatives. - It uses Scrum as its building block. *more attention is paid to dependencies and interoperation between Scrum Teams.

4.2. Dependencies

4.2.1. - Requirements: scope may overlap and implementation may affect each other. should be considered when ordering and selecting items - Domain Knowledge: should be distributed across the Scrum Teams (to minimize interruptions between teams). - Test artifacts: Dependencies of requirements, domain knowledge and software artifacts should drive the organization.

5. EVENTS

5.1. Refinement

5.1.1. Purpose

5.1.1.1. - helps the Scrum team forecast which team will deliver which product Backlog items - identifies dependencies across the teams (teams can monitor and minimize dependencies - makes items ready for selection in the Nexus Sprint Planning.

5.1.1.2. - refinement continues until the product backlog items are suficciently independent to be worked by a single Scrum Team

5.1.2. Frequency, duration and attendance is based on the dependencies in the product backlog Is continous thyoughout the Sprint as necessary and appropriate

5.2. Nexus Sprint Planning

5.2.1. Purpose

5.2.1.1. to coordinate the activities of all Scrum teams for a single sprint to discuss and review the refined product backlog

5.2.2. Attendees

5.2.2.1. - representatives from each Scrum Team

5.2.2.2. - all members of the Scrum Teams (to minimize communication issues)

5.2.3. Output

5.2.3.1. Nexus Sprint Goal

5.2.3.1.1. describes the purpose that will be achieved by scrum teams in the sprint sum of all the work and Sprint goals of the scrum teams

5.2.4. Sprint planning

5.2.4.1. - After understanding the overall work for the Nexus, scrum teams perform their own Sprint Planning - Nexus Sprint Planning is complete when each scrum team has finished individual Sprint Planning.

5.3. NEXUS DAILY SCRUM

5.3.1. Attendees

5.3.1.1. appropriate representatives from individual Dev teams

5.3.2. Purpose

5.3.2.1. to inspect the current state of the integrated increment and to identify integration issues or cross-team dependencies/impacts to inspect progress toward the Nexus Sprint Goal

5.3.2.2. - a set of Sprint Goals aligned to the Nexus Sprint Goal - each Scrum Team's Sprint Backlog - a Single Nexus Sprint Backlog

5.3.3. - was the previous day's work successfully integrated? - what new dependencies or impacts have been identified? - what information needs to be shared across teams in the Nexus?

5.3.4. Daily Scrum

5.3.4.1. issues and work identified during the Nexus daily scrum are taken back to be planned on their individual Daily Scrum

5.4. NEXUS SPRINT REVIEW

5.4.1. held at the end of the Sprint

5.4.2. Purpose

5.4.2.1. to provide feedback on the integrated increment and to adapt the product backlog if needed *it may not be possible to show all work in detail, so techniques may be necessary to maximize stakeholder feedback.

5.4.2.2. Replaces individual Scrum Teams Reviews, because the entire integrated increment is the focus

5.4.3. Output

5.4.3.1. a revised product backlog

5.5. NEXUS SPRINT RETROSPECTIVE

5.5.1. a formal opportunity for a Nexus to inspect and adapt itself and create plans for improvements for the next sprint

5.5.2. Part 1. Make shared issues transparent to all teams. Opportunity for appropriate representatives from across a Nexus to meet and identify issues that have impacted more than a sigle team Part 2. Each Scrum team holding their own Sprint retrospective Part 3. Opportunity for appropriate representatives from the scrum teams to meet again and agree on how to visualize and track the identified actions (allows the Nexus as a whole to adapt)

5.5.3. - Was any work left undone? Did the Nexus generate technical debt? - Were all artifacts, particularly code, daily successfully integrated? - Was the software successfully built, tested, and deployed often enough to prenvent overwhelming accumulation of unresolved dependencies?

5.5.4. Spint Retrospective

6. ARTIFACTS

6.1. Product Backlog

6.1.1. All teams uses the same Product Backlog

6.1.2. PO is accountable for it, including its content, availability and ordering

6.1.3. Ready items - it must be understood at a level where dependencies can be detected and minimized

6.1.4. - professionals who are skilled in the use of various tools and practices - ensure the Scrum Teams whithin the Nexus understand and implement the practices and tools needed to detect dependencies and frequently integrate all artifacts to the definition of "Done" *team members may also work as Dev team members in one or more Scrum Teams.

6.2. Integrated Increment

7. ROLES

7.1. NEXUS INTEGRATION TEAM

7.1.1. Role

7.1.1.1. - Coordinate, coach and supervise the application of Nexus and the operation of Scrum - Highlight awereness of dependencies and cross-team issues - Accountable for ensuring that a "done" integrated increment once every sprint - Might perform work from product backlog - provides a focal point of integration for the Nexus (scrum teams may address integration issues)

7.1.2. Team

7.1.2.1. Product Owner, Scrum Master and Nexus Integration Team Members *members of the Nexus Integration Team are often also members of the individual Scrum teams (they must give priority to their work on the Nexus Integration Team to thelp ensure that the work to relsolve issues affecting many teams has priority)

7.1.2.2. Composition of the team may change over time to reflect the current needs of a Nexus

7.1.3. PO

7.1.3.1. is responisble for maximizing the value of the product and the work performed and integrated by the scrum teams is a member of the NIT

7.1.4. SM

7.1.4.1. - has overall responsibility for ensuring the Nexus framework is understood and enacted *may be a Scrum Master in one or more of the Scrum Teams

7.1.4.2. responsible for delivering done increments

7.1.5. team Members

7.2. SCRUM TEAMS

8. DEFINITION OF 'DONE'

8.1. Nexus Integration Team is responsible for a definition of done

8.2. All Scrum Teams adhere to the same definition (individual scrum teams can apply a more stringent definition of "done", but no less rigorous criteria.

8.3. The increment is 'done' when integrated, usable and potentially releasable by the PO