PSM II – Scaled Scrum

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of rework caused by choosing an easy solution “now” instead of using a better approach that would take longer. Like any other debt, a large accumulation of Technical Debt (bad code) can impact future maintainability of the product. A Technical debt reduces Transparency.
It misleads the Product Owners, Scrum Masters and even the developers with their assumptions about the “Current state” of the System. For example, if Product Backlog item A is assumed to be completed in a day, it might take three days for it to complete, because of unseen bad code or Technical Debt.

The Product becomes more unstable, as more functionality / features added over bad code (or existing technical debt). For example, suppose that the team decided to delay some important refactoring to facilitate an early release. Technical debt starts to accrue at that point, and it may not map cleanly to specific items on the Product Backlog. It is far more likely to impact components which cross-cut a range of features. Moreover, if the necessary refactoring is significant it could impact the entire product, and it could affect features in uneven ways.

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.

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.

Read the Question Carefully. The Product backlog provides a Single View of all the Product Backlog items. However, the Nexus Sprint Backlog provides a single view of all the Product Backlog items in a Sprint, across all teams.

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.

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.

The Nexus Integration Team is responsible for a Definition of “Done” that can be applied to the Integrated Increment developed each Sprint. That doesn’t mean that the Nexus integration team members are the only ones who define the Definition of Done. The Nexus Integration Team make sure there is a DOD which works across all the teams. Everyone in the Nexus needs to contribute to creating a usable increment that meets certain standards.
Each Sprint, all Scrum Teams have a “Done” Increment which integrates with the other “Done” Increments.

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 can choose to apply a more stringent definition of “Done” within their own teams but cannot apply less rigorous criteria than agreed (in nexus) for the Increment.

The Scrum Master ensures that the Developers in the Scrum Team are meeting and teaches the Scrum Team to keep the meetings within the time-box.

If increments are not integrated every Sprint then,

• The state of the product becomes unclear (due to undiscovered problems that could arise during integration and complete product increment tests).
• The Product Owner would not know whether the increment he/she was presented is potential shippable.
• It would not be transparent to the organization what the next reasonable steps would be.

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 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) Product Backlog Items will be then be selected by an appropriate Scrum Team 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.
3) 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.
4) Each Scrum Team then plans its own Sprint. They interact with other teams to share newly found dependencies or update the existing dependencies.

The outcomes of a Nexus Sprint Planning meeting are:
1) A set of Sprint Goals that align with the overarching Nexus Sprint Goal
2) Each Scrum Team’s Individual Sprint Backlog.
3) Adjustments to the Nexus Sprint Backlog.

The best time to change the Definition of Done is during the Sprint Retrospective where the team discusses how to increase product quality. It is however not mandatory to change it during the Nexus Sprint Retrospective. If needed it can be changed as soon as possible. (as long as all Scrum Team members work towards the change).

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.

Remember the following with respect to dependencies:
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.
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.
Extending the Sprint Length is not an option under any situations. Merging the Team is not possible as well as the team should remain small enough to be flexible.

In the Nexus Framework, there are three backlogs which are used:
1. Product Backlog
2. Nexus Sprint Backlog
3. Scrum Team’s Individual Sprint Backlog
The Nexus Sprint Backlog provides a single view of all the Product Backlog items in a Sprint. The Nexus Sprint Backlog is a compilation of each team’s individual Sprint Backlog. The Nexus Sprint Backlog is the composite of Product Backlog items from the Sprint Backlogs of the all individual Scrum Teams. 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.
The Nexus Sprint Backlog is used to highlight dependencies and the flow of work during the Sprint. It focuses on the coordination between teams to ensure the Nexus Sprint Goal is achieved. The Nexus Sprint Backlog is updated daily, often as part of the Nexus Daily Scrum.

The Nexus Integration Team is a new role in Nexus that consists of:
– The Product Owner.
– A Scrum Master.
– Nexus Integration Team Members.

Selected Developers from each Scrum Team would 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.

The System’s architecture is decided throughout the project, as understanding emerges and the Developers learn more about the project.

In the Cross – Team Refinement Board, more arrows associated to a Product Backlog item indicate high risk due to the number of dependent items impacted.  The Team Refinement Board
visualization helps the teams within the Nexus identify the ‘critical path’ of work throughout the upcoming Sprints. The Team Refinement Board provides the basis for conversations about ways
to remove or minimize the impact of these dependencies.

Nexus is a framework for developing and sustaining scaled product and software development initiatives. It uses Scrum as its building block.

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.

In Nexus, a Product Backlog item can be considered “Done” when the planned functionality has been successfully added to the product and integrated into the final Increment.
All Scrum Teams are responsible for developing and integrating their work into an Increment, however the Nexus Integration Team owns the accountability.
Nexus Sprint Reviews replace Individual Sprint Reviews with the expectation that the stakeholders would get a chance to give feedback for the Integrated increment. If there is no feedback, this would be a considered a missed opportunity to adapt. The Value of the Product would be compromised as it depends on client’s feedback.

As Teams starts delaying the integration, more chances of bugs and tech debt rises. The delay might lead to reduced testing, unknown lastminute issues etc.
Thus, all of the answers are true.

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)

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 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 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.
Remember Nexus Sprint Goal = Sum of Sprint Goals Across all the Team \ In a SPRINT $\}+$ the Work done by all the Teams \ 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.

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.

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

The Nexus Sprint Backlog is updated Daily, often as part of the Nexus Daily Scrum.

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.

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.