SPS – Quiz

Explanation
A The scope of the requirements may overlap, and the order in which they 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 to avoid/ reduce dependencies.

Explanation
The Nexus Sprint Backlog is a compilation of each team’s individual Sprint Backlog. It is the composite of Product Backlog items from the Sprint Backlogs of all individual Scrum Teams.

Explanation
Nexus is a framework consisting of roles, events, artifacts, and rules that bind and weave 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.

Explanation
The Nexus Daily Scrum is an event for appropriate representatives from individual Development Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies or cross-team impacts.

Explanation
A Team Member’s knowledge should be distributed across the Scrum Teams to ensure that the teams have the knowledge they need to do their work. This would minimize interruptions between Scrum Teams during a Sprint.

Explanation
During Nexus Sprint Planning, appropriate representatives from each Scrum Team validate and make adjustments to the ordering of the work as created during Refinement events. All members of the Scrum Teams should participate to minimize communication issues.

Explanation
Product Backlog items are deemed “Ready” for the Nexus Sprint Planning meeting when the Scrum Teams can select items to be done with no or minimal dependencies with other Scrum Teams.

Explanation
The Nexus Integration Team is responsible for a definition of “Done” that can be applied to the Integrated Increment developed each Sprint. All Scrum Teams of a Nexus adhere to this definition of “Done”.

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

Explanation
The events in the Nexus framework are appended to, placed around, or replace (in the case of the Sprint Review) regular Scrum events to augment them.

Explanation
Remember Nexus Sprint Goal = Sum of Sprint Goals Across all the Team (In a SPRINT).

Only the Integrated Increment will show if Nexus Sprint Goal Is met. Thus, It is a must that an Integrated Increment Is shown In the Nexus Sprint Reviews

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

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

Note: Product Value does not increase by simply adding more resources to the Scrum Team.

Explanation
The Nexus Integration Team exists to coordinate, coach, and supervise the application of Nexus and the operation of Scrum so the best outcomes are derived

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

Explanation
As with the Scrum framework, the Nexus roles, artifacts, events, and rules are immutable. Although implementing only parts of Nexus is possible, the result is not Nexus

Explanation
During the Nexus Daily Scrum, attendees should focus on each team’s impact on the Integrated Increment and discuss:
1. Was the previous day’s work successfully integrated? If not, why not?
2. What new dependencies have been identified?
3. What information needs to be shared across teams in the Nexus?

Explanation
Dependencies is one of the most important concerns when multiple Scrum Teams work together. 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.

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

Explanation
A Nexus Sprint Review replaces individual Scrum Team Sprint Reviews, because the entire Integrated Increment is the focus for capturing feedback from stakeholders. It may not be possible to show all completed work in detail. Techniques may be necessary to maximize stakeholder feedback.

Explanation
The Nexus Sprint Goal is discussed and formulated during Nexus Sprint Planning.
New dependencies may emerge during Nexus Sprint Planning.
The sequence of work across teams may also be adjusted.

Explanation
The Nexus Sprint Retrospective consists of the three parts:
1. The first part is an opportunity for appropriate representatives from across a Nexus to meet and identify issues that have impacted more than a single team. The purpose is to make shared issues transparent to all Scrum Teams.
2. The second part consists of each Scrum Team holding their own Sprint Retrospective as described in the Scrum framework. They can use issues raised from the first part of 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.
3. The final, 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. This allows the Nexus as a whole to adapt.

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

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

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

Explanation
The best way to remove the uncertainty of a technical nature is to perform experimentation – which is the intent of a SPIKE story. When a story cannot be estimated because the team needs to experiment, the best approach is to write a spike story before working on the main story.

Explanation
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, so Scrum Teams can plan and work on them independently

Explanation
The number, frequency, duration and attendance of Refinement is based on the dependencies and uncertainty inherent in the Product Backlog.

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