PSM II – Scaled Scrum

The Nexus Product Backlog is suggested to be Timeboxed (not mandated) up to $10 \%$ of the capacity of a Scrum Team during a Sprint. However, Inspection and adaption may lead to this being adjusted over time as required.

Nexus Sprint Planning time box would be 8 hours for a 1month Sprint (not mandated). However, in Nexus, Inspection and adaption may lead to this being adjusted over time as required.

Product Owner should focus on:

=> Key Stakeholder Involvement

In order to maximize Product value, the Product Owner should identify the key stakeholders for the product and involve them as necessary throughout the development effort.
=> Product Marketplace
The Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information regarding the marketplace, so that the product value is maximized.
=> Product Release Decisions
The Product Owner is the one and only person who can decide whether to release the latest Increment of the Product. For Product value to be captured, a release of the product must
occur.

There is a single Nexus Sprint Backlog. It is the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. All Scrum Teams maintain their individual Sprint Backlogs.

The Nexus Integration Team is responsible for the Integration issues and Integrated Increment developed each Sprint.

The Retrospective consists of three parts:
Part 1: Nexus Retrospective: Representatives from all the Scrum teams meet to Identify issues that have impacted more than a single Scrum team. The purpose is to make shared issues transparent to all Scrum Teams.
Part 2: Individual Scrum Team Sprint
Retrospectives: Each Scrum Team holds their own Sprint Retrospective as described in the Scrum framework. They can use issues raised from the Nexus Retrospective as input to their team discussions. The individual Scrum Teams should form actions to address these issues during their individual Scrum Team Sprint Retrospectives.
Part 3: Synchronize: Third part is an opportunity for appropriate representatives from the Scrum Teams to meet again and agree on how to visualize and track the identified actions.

Nexus is based on the Scrum framework and uses an iterative and incremental approach to scaling software and product development. Nexus augments (adds to) Scrum minimally with one new role and some expanded events and artifacts. It preserves Scrum.

The Nexus Daily Scrum is the scaled version of the Daily Scrum event from the Scrum framework. The Nexus Daily Scrum is an event which:
1) Inspects the current state of the Integrated Increment against the Nexus Sprint Goal.
2) Is an opportunity to Identifies Integration issues and make them Transparent
3) Identifies newly discovered cross-team dependencies
4) Identifies cross-team impacts.
Appropriate represented Developers from individual Scrum Teams attend the Nexus Daily Scrum.

All Developers from all the Scrum Teams are not required to attend the Nexus Daily Scrum.
However, they are required to attend their Internal Daily Scrum Call.
At least every Nexus Daily Scrum, the Nexus Sprint Backlog should be inspected (adjusted if needed) to reflect the current understanding of the work of the Scrum Teams within the Nexus.
Appropriate Representatives (Developers) from each Scrum Team meet daily to identify if any integration issues exist. If integration issues are identified, this information is transferred back to each Scrum Team’s Daily Scrum.

Scrum Teams use their Daily Scrum making sure to address the integration issues raised during the Nexus Daily Scrum

The Scrum Master in the Nexus Integration Team has the overall responsibility for ensuring the Nexus framework is understood and enacted.

The Nexus Sprint Goal is an objective set for the Sprints across Teams.

The Nexus Sprint Goal is discussed and finalized during Nexus Sprint Planning. The Nexus Sprint Goal is then communicated to the rest of the Individual Scrum Teams to reflect the shared purpose of Nexus.

Individual Scrum Team Sprint Goals are set during Individual Scrum Team Sprint Planning sessions. (not during the Nexus Sprint Planning).
The Nexus Sprint Goal describes the purpose that will be achieved by all the Scrum Teams during the Sprint.
Nexus Sprint Goal = Sum of Sprint Goals Across all the Team { In a SPRINT }+ the Work done by all the Teams {In a SPRINT }

The Nexus Integration Team coaches the individual Scrum Teams on the necessary development, infrastructural, or architectural standards required by the organization to ensure the development of quality Integrated Increments.

The Nexus Sprint Backlog will be created during Nexus Sprint Planning. This will be a combination of the Sprint Backlogs created by individual Scrum Teams and will additionally highlight cross team dependencies.

The Nexus Sprint Backlog contains the Product Backlog Items being worked on by all of the teams plus the subset of work that identifies dependencies between teams. It also includes the work done by the individual teams to ensure that the work is delivered and fully integrated.

The primary owner is the Nexus Integration Team. If any one on any of the Scrum teams identifies new work that would extend across two or more teams in the Nexus, they would be able to add it to the Nexus Sprint Backlog through the team’s representative on the Nexus Integration Team.
The members of the Nexus Integration Team “are often members of the individual Scrum Teams in the Nexus” and that their membership in the Nexus Integration Team “takes precedence over individual Scrum Team membership”. That would mean that the members of the Nexus Integration Team are responsible for and accountable for ensuring that the cross-team work items added to the Nexus Sprint Backlog are complete.

Nexus provides opportunities to change the process, product structure, and communication structure to reduce or remove these dependencies.

Different Scrum Teams working on the same Product (in Nexus) can:
– Have different Sprint Lengths.
– Have different Scrum Masters.
– Have only one Product Owner.
– Have only one Product Backlog.

It is the responsibility of the Developers to work with the other teams to make sure that their Sprint work is aligned to create an integrated Increment.

The purpose of the Nexus Sprint Retrospective is to plan ways to increase quality and effectiveness across the whole Nexus. The Nexus inspects how the last Sprint went with regards to individuals, teams, interactions, processes, tools, and its
Definition of Done. In addition to individual team improvements, the Scrum Teams’ Sprint
Retrospectives complement the Nexus Sprint
Retrospective by using bottom-up intelligence to focus on issues that affect the Nexus as a whole.
The Nexus Retrospective consists of three parts:
Part 1: Nexus Retrospective: Representatives from all the Scrum teams meet to Identify issues that have impacted more than a single Scrum team. The purpose is to make shared issues transparent to all Scrum Teams.
Part 2: Individual Scrum Team Sprint
Retrospectives: Each Scrum Team holds their own Sprint Retrospective as described in the Scrum framework. They can use issues raised from the Nexus Retrospective as input to their team discussions. The individual Scrum Teams should form actions to address these issues during their individual Scrum Team Sprint Retrospectives.
Part 3: Synchronize: Third part is an opportunity for appropriate representatives from the Scrum Teams to meet again and agree on how to visualize and track the identified actions.

Nexus Sprint Planning is conducted to coordinate the activities of all Scrum Teams for a single Sprint. Note: The following should be done prior to the Nexus Sprint Planning:
1) The Product Backlog should be adequately refined. Having a Product Backlog refined to “Ready” is likely to be an essential prerequisite to allow planning to proceed effectively.
2) The Dependencies within the Product Backlog items should be identified and removed or minimized.
During Nexus Sprint Planning:
1) Appropriate Representatives (\& not all Team Members) from each Scrum Team meet to review the refined Product Backlog. Each Scrum Team further validates and adjusts the ordering of the Backlog items (created during Refinement events). The ordering will help reduce dependencies between Scrum Teams in the Nexus during the Sprint.
2) The Team will be working a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal. The Nexus Sprint Goal will be formulated in Nexus Sprint Planning. It will describe the purpose that will be achieved by the Nexus during the Sprint.
3) Product Backlog Items will be then be selected by an appropriate Scrum Team (in their individual Sprint Backlogs) that has the skills required to deliver them with no (or minimal) dependencies on other Scrum Teams. The Scrum Team should have all the cross functional skills required to translate the Product Backlog Item into an integrated Increment by the end of the Sprint.
4) Each Scrum Team then plans its own Sprint (Individual Teams Sprint Planning event), Sprint Goal which will align to the Nexus Sprint Goal. They interact with other teams to share newly found dependencies or update the existing dependencies.

The Nexus Framework helps teams solve common scaling challenges like:
1. Reducing cross-team dependencies
2. Preserving team self-management and transparency
3. Ensuring accountability.
Dependencies is one of the most important concerns when multiple Scrum Teams work together. Nexus helps to make transparent dependencies. These dependencies are often caused by mismatches related to:
1. Product structure: The degree to which different concerns are independently separated in the product will greatly affect the complexity of creating an integrated product release. The scope of the requirements may overlap if not separated as needed. The order in which these requirements are implemented may also affect each other. While ordering the Product Backlog and selecting the Product Backlog items in the Sprint Backlog, one should make sure that such dependencies are accommodated.
2. Communication structure: The way that people communicate within and between teams affects their ability to get work done; delays in communication and feedback reduce the flow of work.

Under the Scrum and Nexus Frameworks, No one “reports” to the Nexus Integrations Team. Developers and Scrum Masters working in an Individual Scrum Teams can be a part of the Nexus Integration Team, however they do not report to anyone.

The Nexus Framework helps teams solve common scaling challenges like:
1. Reducing cross-team dependencies
2. Preserving team self-management and transparency
3. Ensuring accountability.
Dependencies is one of the most important concerns when multiple Scrum Teams work together. Nexus helps to make transparent dependencies. These dependencies are often caused by mismatches related to:
Product structure: The degree to which different concerns are independently separated in the product will greatly affect the complexity of creating an integrated product release. The scope of the requirements may overlap if not separated as needed. The order in which these requirements are implemented may also affect each other. While ordering the Product Backlog and selecting the Product Backlog items in the Sprint Backlog, one should make sure that such dependencies are accommodated.

2. Communication structure: The way that people communicate within and between teams affects their ability to get work done; delays in communication and feedback reduce the flow of work.

The Nexus Sprint Backlog will be created during Nexus Sprint Planning. This will be a combination of the Sprint Backlogs created by individual Scrum Teams and will additionally highlight cross team dependencies.

The Nexus Sprint Backlog contains the Product Backlog Items being worked on by all of the teams plus the subset of work that identifies dependencies between teams. It also includes the work done by the individuals teams to ensure that the work is delivered and fully integrated.

As the Product Backlog items are refined and made ready, indicators of which Scrum team will do the work inside a Sprint are made transparent in the Nexus Sprint Backlog.
The Nexus Sprint Backlog makes all the Scrum Team’s (not just the Integration Team) work transparent by exposing the dependencies.

Cautiously, the answer is A.
Option B: Increase the refinement time to clarify on what needs to be completed, does not seem to be a bad option, however the team has no issues understanding the work which needs to be completed. They have issues working with the dependencies. So, this option is the wrong answer.

Option C is not a bad answer either, however a quarterly meeting is a long gap for biweekly and monthly Sprints and would not help much.
The only option left is Option A.

The blue vertical arrow shows dependency across teams within a single Sprint. One team will
build an item in a Sprint that is needed by an item that will be delivered in the same Sprint by a
different team. This dependency gives little room for delay or unexpected complexity. This is a
high-risk relationship.

Each Scrum Team’s Daily Scrum complements the Nexus Daily Scrum by creating plans for the day, focused primarily on addressing the integration issues raised during the Nexus Daily Scrum.

When Multiple Scrum teams working on 1 product, there would be a shared understanding of what Definition of “Done” means. This can be called the Nexus Definition of Done.

When multiple teams are working on the same product, there can be more than one Definition of “Done” for all of them. Each team might be working on a different part of the product (e.g. desktop application, mobile application, web application), or simply have different styles of work. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with a shared Definition of Done. They can add their own specific criteria on top of this Definition of “Done” Criteria.
When different teams are working on the same product, they must observe a common Definition of Done which qualifies for the integrated increment.
The Definition of Done observed by an individual team should reinforce and not contradict any shared Definition for a product increment. For example, a team may incorporate a shared DoD as a subset of their own.

Scrum Teams Definition of “Done” = Nexus Definition of “Done” + Optional Scrum Team Specific Definition of “Done” Criteria.

Individual Scrum Teams may choose to apply a more stringent definition of “Done” within their own teams but cannot apply less rigorous criteria than agreed for the Increment.

Developers (or selective Experts) should design and build a platform / a foundation (of NonFunctional requirements and High Value
Functions) which would be used by as a Shared Architecture. Each set of Scrum Team would work on this (to begin with) and work with each other to enhance it with time. Developers within the Scrum Team are responsible for creating the architecture. The architectural and technical design discussions start as early as sprint planning and continue throughout the sprint as the design is being implemented (i.e. coding/construction). Remember a Non-functional foundation (with no designs) and just some high value function is all that is needed in the beginning. Scrum Developers will work on it together as requirements get translated to Product Backlog items and the Product starts to build.

The Nexus Daily Scrum is the scaled version of the Daily Scrum event from the Scrum framework. The Nexus Daily Scrum is an event which:
1) Inspects the current state of the Integrated Increment against the Nexus Sprint Goal.
2) Is an opportunity to Identifies Integration issues and make them Transparent
3) Identifies newly discovered cross-team dependencies
4) Identifies cross-team impacts.
Appropriate represented Developers from individual Scrum Teams attend the Nexus Daily Scrum. All Developers from all the Scrum Teams are not required to attend the Nexus Daily Scrum. However, they are required to attend their Internal Daily Scrum Call.

Refinement of the Product Backlog at scale serves a dual purpose.
– It helps the Scrum Teams forecast which team will deliver which Product Backlog items
– it identifies dependencies across those teams.

Ideally, the Product Backlog should be adequately refined with dependencies identified and removed or minimized prior to Nexus Sprint Planning. However New dependencies may emerge during Nexus Sprint Planning.
Note: Sprint Planning is another opportunity to identify and eliminate or reduce dependencies between Product Backlog Items, so Scrum Teams can plan and work on them independently.

Some of the benefits of Self-organizing team are:

• Team buy-in and shared ownership
• Motivation, which leads to an enhanced performance level of the team
• Innovative and Creative environment conducive to growth
• Increased Self Accountability \& Commitment to achieving the goals of the Scrum Team.

The Nexus Sprint Goal is discussed and finalized during Nexus Sprint Planning.