PSM II – Scaled Scrum

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 Sprint Retrospective is a formal opportunity to inspect and adapt itself. The Nexus Sprint Retrospective enables the team to create a plan for improvements which would be enacted during the next Sprint to ensure continuous improvement.
The Nexus Sprint Retrospective occurs after the Nexus Sprint Review and prior to the next Nexus Sprint Planning. Because they are common scaling dysfunctions, every Retrospective should address the following subjects:
– Was any work left undone? Did the Nexus generate technical debt?
– Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?
– Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?

The Nexus Scrum Master may also be a Scrum Master in one or more of the Scrum Teams.

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 Integration Team consists of professionals who are skilled in the use of tools, various practices, and the general field of systems engineering. Nexus Integration Team Members ensure the Scrum Teams within the Nexus understand and implement the practices and tools needed to detect dependencies, and frequently integrate all artifacts. Nexus Integration Team Members are responsible for coaching and guiding the Scrum Teams in a Nexus to acquire, implement, and learn these practices and tools.

Additionally, 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 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.

Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories. Team velocity has nothing to do when it comes to prioritizing and choosing items in a teams Sprint backlog.

The Sprint Backlog is created during the beginning of the Sprint. Developers within the Scrum Team work with the Product Owner to pull in the work, into their individual Sprint Backlogs. The Sprint Backlog captures all the work which the Developers identifies as necessary, to meet the Sprint Goal.

The Objectives of the Nexus Sprint Review are:
1. To review the completed integrated Increment
2. Generate feedback based on new learnings and viewpoints.
The Nexus Sprint Review is held at the end of the Sprint.
A Nexus Sprint Review replaces individual Scrum Team Sprint Reviews, because the entire Integrated Increment is the focus for capturing feedback from stakeholders.
The Nexus Sprint Review is conducted so feedback can be provided by all the stakeholders on the Integrated Increment that has been built over the Sprint. It may not be possible to show all completed work done by each team in detail. Techniques may be necessary to maximize stakeholder feedback.

Representatives of each of the Scrum Teams attend the Nexus Sprint Review. The Scrum teams within themselves, decide the most appropriate people to attend. This may change over time and vary from one Nexus Sprint Review to another.

Adjustments may be made to the Product Backlog based on the feedback provided by the Stakeholders. The result of the Nexus Sprint Review is a revised Product Backlog. It may not be possible to show all completed work done by each team in detail.

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 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.

Only One Product Backlog and Only One Product Owner can exist for a Product (Regular Scrum framework or in Nexus).
The Same Product Owner may work as a Product Owner for multiple Products. (Not Recommended)
The Product Owner can delegate the following capabilities to Developers:
1. Clearly expressing Product Backlog items;
2. Ordering the items in the Product Backlog to best achieve goals and missions
Note:
A) If there are 20 Products, each Product should have a single assigned Product Owner. This does not mean that we have 20 different individuals working on these 20 Products. It means that no two people can act as a Product Owner on a single product.

B) 5 Product Owners can be assigned 4 products each.
Example:

• Charles can be a Product Owner for Products 1,2,3, 4
• James can be a Product Owner for Products 5,6,7,8
• John can be a Product Owner for Products 9,10,11,12
• Mathew can be a Product Owner for Products 13,14,15,16
• Roger can be a Product Owner for Products 17,18,19,20

Few factors which need to be consider for the sprint length are:
Risk Appetite and Market viability
One of the factors to be considered is the risk appetite of the business as well as the market viability. In scenarios where competition is stiff, the business might not have an appetite to take a risk and would like to deliver products frequently. The sprint duration is accordingly planned and with low risk appetite, the team might plan for a shorter duration.
Uncertainty
When there is uncertainty with respect to the change, technology stack and velocity, it is better to go for shorter duration so that the team would get opportunities to get more frequent feedbacks from the stakeholders as well as will get more opportunities to inspect and adapt accordingly.

Only One Product Backlog and Only One Product Owner can exist for a Product (Regular Scrum framework or in Nexus). Multiple Scrum Teams work on the Same Product Backlog. Thus, the same Product Owner would participate in the Nexus Sprint Planning sessions and Team Specific Sprint Planning sessions, as needed.
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.

A Product owner can act as Product Owner for more than one Products however this is not recommended.
Remember:
A) For a given Product, there should be only one Product Owner. E.g. Charles and John both cannot be Product Owners for the same Product (Product XYZ) in an Organization. One Product can only have one Product Owner.

B) The same person can be a Product Owner for more than one Products. This might not be recommended, however is still allowed in Scrum. For e.g Charles can be a Product Owner for Product A and Product B, at the same time.
Thus Both A and B are true.

The Nexus Scrum Master may also be a Scrum Master in one or more of the Scrum Teams.

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.

Nexus Integration Team:

• Does not do the Integration work themselves. They guide the Scrum Teams to do it.
• Does not coordinate the day to day work between the Scrum Teams. It is the Scrum Teams responsibility to work with the other Teams to create an integrated Increment.

Nexus Integration Team Members Raises Transparency by coaching and guiding the Scrum Teams to acquire, implement, and learn the Nexus practices and needed tools.
The Nexus Integration Team will take ownership of integration issues. However, they may not necessarily do the work required to resolve these when they occur. They may work with 1 or more Scrum Teams to help them resolve issues around integration. At other times they may deliver tools and technology to help make integration run more smoothly.
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.

If the primary responsibility of the Nexus Team Member is satisfied, Nexus Integration Team Members may also work as Developers in one or more Scrum Teams.
It is the responsibility of the Scrum Team Members to work with the other teams to make sure that their Sprint work is aligned to create an integrated Increment.

Nexus is a framework which consist of roles, events, artifacts, and rules that bind 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. Remember it says approximately three to nine teams. Its only an approximation and recommendation.

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.

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.

The Nexus Integration Team owns responsibility for the:
– Integration issues.
– Integrated Increment which needs to be produced every Sprint.

Nexus scales the value that a group of Scrum Teams, working on a single Product. Nexus reduces the complexity that those teams encounter as they collaborate to deliver an integrated, valuable, useful product Increment at least once every Sprint.

Scrum promotes a single integrated increment end of each sprint. The Nexus Integration Team owns responsibility for the:

• Integration issues.
• Integrated Increment.
  If the integrated increment is missing, then probably the team responsible for it is nonexistent. (or the team did not meet its definition of done)

Factors Impacting the Sprint Length:
– Risk of being disconnected from the Stakeholders
– Level of uncertainty over the technology used and velocity
– Market Competition \& Time to release.

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.

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.
Remember: The Nexus Daily Scrum is not the only time Scrum Teams in the Nexus are allowed to adjust their plan. Cross-team communication can occur throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Scrum Teams should merge their increments at least once during the Sprint. They can do this as many times needed in a Sprint. There is no such “Stabilization Period “defined in a Sprint.

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 Product Owner does not assign work to individual Scrum Teams or Sprint Backlogs. Developers in the Scrum Team work with the Product Owner to pull the items during Nexus Sprint Planning. It is not necessary that equal items be assigned to the Scrum Teams.

In Scrum, Product Backlog refinement is an ongoing activity for a single team; however, it is not a mandatory event. Due to the added complexity of many teams working together on a single product, Refinement is an official and required event in the Nexus Framework. Teams in a Nexus need to be involved in a shared Refinement event, because Refinement is focused on decomposing Product Backlog Items enough so that the teams can understand which work they could deliver and in what sequence over upcoming Sprints.

Nexus Sprint Planning is complete when each Scrum Team has finished their individual Sprint Planning events.

The Nexus Sprint Goal is formulated during Nexus Sprint Planning. The Nexus Sprint Goal is an objective set for the Sprint. It is the sum of all the work and Sprint Goals of the Scrum Teams within the Nexus. The Nexus should demonstrate the functionality that it has “Done” developed to achieve the Nexus Sprint Goal at the Nexus Sprint Review in order to receive stakeholder feedback.