Chapter 11

Scaled Professional Scrum

As you’ve learned by now, Scrum is a simple framework for delivering complex products such as software by using an empirical approach in which a team delivers value in small increments, inspects the results, and adapts their approach as needed based on feedback. The Scrum framework consists of a simple set of events, roles, and artifacts, bound together by practices and brought to life by the Scrum Values.

That’s fine for a Scrum Team of 10 or fewer members, but what about those larger and more complex products that require more than 10 Developers? More than 50? Any situation where there is a single product, a single Product Backlog, and a single Product Owner but multiple teams of Developers working on the product is known as scaling. In other words, scaling occurs whenever there is an opportunity for increased chaos caused by inter-team dependencies as they all work on a common product.

Over the past decade, our industry has seen a flurry of conversations about the “problem” of scaling development. Many organizations have tried to scale and failed. Many books and conference presentations have dived deep. Frameworks of all sorts have been introduced. What is evident is that mindless adoption of agile values and principles won’t scale to multiple teams—no matter how hard an organization tries or how much they spend. In other words, flaccid/zombie/mechanical Scrum won’t scale. An organization must nail it before they scale it!

When the signers of the Agile Manifesto got together in 2001, they shared ideas about software development. Their discussion resulted in the Agile Manifesto. Although they may not have foreseen the tumult of scaling agile development—or the lucrative consulting opportunities—they knew that values and principles scale but that practices are context sensitive. Although it is hard to continuously improve, it is the only way to scale. Organizations cannot buy their way into successful scaling. They must keep the values and principles that single-team Scrum introduced while continuing to inspect and adapt as they add additional teams to product development.

This chapter covers scaling and how to control the chaos as multiple teams collaborate to build a single product. This chapter also introduces the Nexus Scaled Scrum framework as well as how Azure DevOps can support a Nexus to plan and manage work at scale.

Note In this chapter, I am using the customized Professional Scrum process, not the out-of-the-box Scrum process. Please refer to Chapter 3, “Azure Boards,” for information on this custom process and how to create it for yourself.

The Nexus Framework

As Scrum has increased in popularity, so has the need for Scrum Teams to work together in delivering products. When organizations want multiple Scrum Teams to work on a product, they often find that the Scrum framework alone is not enough. When multiple teams work on a product, the productivity they enjoy from using single-team Scrum may erode as additional teams share in the work. This is primarily due to the dependencies between the teams. That is because, to scale successfully, teams should not be left as separate units. In fact, the teams themselves must integrate into a connected system and identify as a common group, which is what is referred to as a Nexus. A Nexus is a relationship or connection between people or things. Nexus is Scrum at scale.

Note Disclaimer: I am biased toward the Nexus framework. I helped create it along with Ken Schwaber. In addition, we created Scaled Professional Scrum, which is Scrum.org’s instantiation of the Nexus framework. You can learn more about the Nexus and Scaled Professional Scrum at www.scrum.org/nexus.

The Scrum framework is the foundation for Nexus and, as you can see in Figure 11-1, looks very similar to the Scrum framework. The Nexus framework retains the simplicity of its origins, adding additional roles, events, artifacts, and rules only where necessary to enable successful large product development initiatives. Schwaber describes the Nexus as an “exoskeleton” to Scrum.

FIGURE 11-1 The Nexus framework.

Note The Nexus contains 3–9 Scrum Teams but only one Product Owner. This is possible because on each of those Scrum Teams, the Product Owner is a role, not a separate person. All of those roles are played by one person (for example, Paula).

As you can see, the Scrum framework is still intact within the Nexus framework. The same events, artifacts, and roles exist. You might have also noticed that the Nexus framework adds some additional elements. Refinement becomes a proper event. Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective all have complementary events—identifiable by the word “Nexus” in their name. A Nexus Sprint Backlog, Nexus Sprint Goal, and Integrated Increment have also been added, along with a new role called the Nexus Integration Team. All new Nexus elements are listed in Table 11-1.

TABLE 11-1 The Nexus framework adds additional elements to Scrum.

Additional role	Additional events	Additional artifacts
Nexus Integration Team	Refinement	Nexus Sprint Backlog
	Nexus Sprint Planning	Nexus Sprint Goal
	Nexus Daily Scrum	Integrated Increment
	Nexus Sprint Review
	Nexus Sprint Retrospective

The Nexus is about identifying and mitigating dependencies. But what are dependencies? You might imagine a software or component dependency (for example, service A depends on component B). That is just one kind of dependency. Dependencies can also be people, domain, and technology in nature. For example, different Developers on the same or different teams can have different skill sets, different domain experiences and levels, different platforms and tools, and different permissions and access levels across people and teams.

It’s especially important to identify cross-team dependencies. These are dependencies where two or more teams within the Nexus must coordinate their work in order to deliver Done functionality (for example, team A handles appointment scheduling and team B handles notifications). Hopefully, over time, each team can become a truly cross-product feature team, alleviating most dependencies.

External dependencies are the riskiest—just the same as for single-team Scrum. For example, a Scrum Team that is required to perform user acceptance testing (UAT) won’t stand a chance when trying to scale. External dependencies like these must be solved prior to scaling.

Nexus Process Flow

A Nexus consists of multiple cross-functional Scrum Teams working together to deliver a releasable Integrated Increment by at least the end of each Sprint. Based on dependencies, the teams self-manage and select the most appropriate members to do specific work.

Here is a high-level description of the Nexus process flow:

• ■   Product Backlog Refinement   The Product Backlog must be decomposed so that dependencies are identified and removed or minimized. PBIs are refined into thinly sliced pieces of functionality and the team likely to do the work is identified.

• ■   Nexus Sprint Planning   Appropriate representatives from each Scrum Team meet to discuss and review the refined Product Backlog. They select PBIs for each team. Each Scrum Team then plans its own Sprint, interacting with other teams as appropriate. The outcome is a set of Sprint Goals that aligns with the overarching Nexus Sprint Goal, each Scrum Team’s Sprint Backlog, and a single Nexus Sprint Backlog. The Nexus Sprint Backlog makes the work of all the Scrum Teams’ selected PBIs and any dependencies transparent.

• ■   Development   All teams frequently integrate their work into a common environment that can be tested to ensure that the integration is done. All teams work from a common Definition of Done.

• ■   Nexus Daily Scrum   Developers representing each Scrum Team meet daily to identify any current integration issues. This information is transferred back to each Scrum Team’s Daily Scrum. Scrum Teams use their Daily Scrum to create a plan for the day, making sure to address any integration issues raised during the Nexus Daily Scrum.

• ■   Nexus Sprint Review   The Nexus Sprint Review is held at the end of the Sprint for stakeholders to provide feedback on the Integrated Increment that the Nexus has built over the Sprint. All Scrum Teams meet with stakeholders to review the Integrated Increment. Adjustments are made to the Product Backlog.

• ■   Nexus Sprint Retrospective   Appropriate representatives from each Scrum Team meet to identify shared challenges. Each Scrum Team then holds individual Sprint Retrospectives. Appropriate representatives from each team meet again to discuss any actions needed based on shared challenges. This provides bottom-up intelligence to the entire Nexus.

Nexus Integration Team

The Nexus Integration Team is a new role. It is a Scrum Team within the Nexus that is accountable for ensuring that a Done, Integrated Increment is produced at least once every Sprint. Whereas the individual Scrum Teams are responsible for doing the actual building and delivering of a Done, Integrated Increment, the Nexus Integration Team remains accountable. This means that if the individual Scrum Teams can’t or won’t solve integration issues, the Nexus Integration Team must jump in and do that work. The Nexus Integration Team provides transparent accountability and a focal point for Nexus integration. Integration includes resolving any technical or nontechnical, cross-team constraints that may impede a Nexus’s ability to deliver a constantly Integrated Increment.

The Product Owner is part of the Nexus Integration Team. There must also be a Scrum Master and enough Developers to help with the types of dependency and integration issues that the Nexus might face that Sprint. The Scrum Master in the Nexus Integration Team has overall responsibility for ensuring the Nexus framework is understood and enacted. This Scrum Master may also be a Scrum Master in one or more of the Scrum Teams in that Nexus. Nexus Integration Team composition may change between Sprints—ideally during Sprint Retrospective.

The Developers in the Nexus Integration Team typically consist of professionals who are skilled in the use of tools and relevant engineering practices (for example, DevOps). Nexus Integration Team members ensure that the Scrum Teams within the Nexus understand and implement the relevant tools and practices necessary to detect and mitigate dependencies. These teams must also frequently integrate all artifacts according to the Definition of Done.

Nexus Integration Team members are responsible for facilitating, coaching, and guiding the Scrum Teams in a Nexus to acquire, implement, and learn these practices and tools. Only in times of emergency—when the Nexus grinds to a halt and the individual Scrum Teams can’t do the work—will the Nexus Integration Team members do that work. Additionally, the Nexus Integration Team coaches the individual Scrum Teams on the necessary development, infrastructural, or architectural practices and standards required by the organization to ensure the development of quality Integrated Increments.

Note It’s important to note that the Nexus Integration Team is not a separate team with separate individuals. It is a team of individuals who are already working in the Nexus. The Developers come from other Scrum Teams in the Nexus. They leave that team temporarily when Nexus Integration Team work demands their attention.

Membership in the Nexus Integration Team must take precedence over Scrum Team commitments. For example, a Developer from team #3 who is also on the Nexus Integration Team must drop what they are doing on team #3 and work on the Nexus Integration Team when the Nexus experiences a demanding issue that the teams can’t solve for themselves.

Nexus Events

The Nexus framework defines additional events to complement their respective single-team Scrum events. Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospectives are augmented at scale to provide opportunities for cross-team collaboration and bottom-up intelligence. The duration of each Nexus event is guided by the length of the corresponding events from single-team Scrum as described in the Scrum Guide. The Nexus events are timeboxed in addition to their corresponding Scrum events. The duration of those timeboxes is up to the Nexus to decide.

Refinement

In single-team Scrum, Product Backlog refinement is the act of breaking down and further defining PBIs into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. In single-team Scrum, Product Backlog refinement is not an event. It is not even required. The Scrum Team decides if, when, and where this practice will occur. As the Product Backlog goes through seasons of change, more or less refinement will be necessary.

In the Nexus, Product Backlog Refinement is now an event and it is required. The when and where are up to the Nexus. Refinement of the Product Backlog at scale serves a dual purpose. It identifies dependencies across the teams, and it helps those teams forecast which will deliver which PBIs. This transparency allows the teams to monitor and minimize dependencies. Refinement of PBIs by the Nexus continues until the PBIs are sufficiently independent to be worked on by a single Scrum Team without excessive coordination.

The number, frequency, duration, and attendance of the Refinement event are based on the dependencies and uncertainty inherent in the Product Backlog. PBIs pass through different levels of decomposition from very large and vague requests (for example, epics or features) to more actionable-sized work that a single Scrum Team could deliver inside a Sprint (for example, user stories). Cross-team Refinement should be continuous throughout the Sprint as necessary and appropriate as the Product Owner decides which larger PBIs might be of interest in approaching Sprints and which teams should develop which PBIs. Individual team Product Backlog refinement also occurs continuously in order for each team’s PBIs to be ready for selection in Nexus Sprint Planning.

Nexus Sprint Planning

The purpose of Nexus Sprint Planning is to coordinate the high-level activities of all Scrum Teams in a Nexus for a single Sprint. The Product Backlog should be adequately refined with dependencies identified and removed, or at least minimized, before Nexus Sprint Planning. The Product Owner provides domain knowledge and guides selection and priority decisions.

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

Note Many of the Nexus events require the “appropriate representatives” to attend. This means that the Nexus should decide which representatives from each Scrum Team should attend. Each team should have at least one representative, but some teams might send more than one. The representatives can rotate each meeting or always be the same. Let the Nexus—and the Scrum Teams within the Nexus—make those decisions.

The Product Owner discusses the Nexus Sprint Goal during Nexus Sprint Planning. The Nexus Sprint Goal describes the purpose or expected outcome that will be achieved by the Scrum Teams during the Sprint. After the overall work for the Nexus is understood, Nexus Sprint Planning continues, with each Scrum Team performing their own individual Sprint Planning. The Scrum Teams should continue to share newly discovered dependencies with other Scrum Teams in the Nexus. Each Scrum Team then develops their own Sprint Backlog—interacting with other teams as appropriate. Nexus Sprint Planning is complete when every Scrum Team has finished their individual Sprint Planning events.

New dependencies may emerge during Nexus Sprint Planning. They should be made transparent and minimized. The sequence of work across teams may also be adjusted. An adequately refined Product Backlog will minimize the emergence of new dependencies during Nexus Sprint Planning. The outcome of Nexus Sprint Planning is a set of Sprint Goals that aligns with the overarching Nexus Sprint Goal, each Scrum Team's Sprint Backlog, and a single Nexus Sprint Backlog. The Nexus Sprint Backlog makes the work of all the Scrum Teams’ selected PBIs and any dependencies transparent.

Nexus Daily Scrum

The Nexus Daily Scrum, much like the Daily Scrum, is an event for Developer representatives from the individual Scrum Teams. They will meet to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies or cross-team impacts.

During the Nexus Daily Scrum, attendees focus on each team’s impact on the Integrated Increment. They discuss whether the previous day’s work successfully integrated and what new dependencies or impacts have been identified. The output of this event is a shared understanding of the information that must be shared across teams in the Nexus.

The Developer representatives use the Nexus Daily Scrum to inspect progress toward the Nexus Sprint Goal. At least during every Nexus Daily Scrum, the Nexus Sprint Backlog should be updated to reflect the current understanding of the work of the Scrum Teams within the Nexus. The representatives take these observations, issues, and work that were identified during the Nexus Daily Scrum back to their individual Scrum Teams for planning inside their respective Daily Scrums.

Nexus Sprint Review

The Nexus Sprint Review occurs at the end of the Sprint to provide feedback on the Integrated Increment that the Nexus has built during that Sprint and to adapt the Product Backlog as needed. A Nexus Sprint Review replaces the need for individual Scrum Team Sprint Reviews, because the entire Integrated Increment is typically the focus for capturing feedback from stakeholders. The goal of any Sprint Review is to obtain stakeholder feedback. This feedback will result in a revised Product Backlog.

Because of the amount of Done functionality, it may not be possible to inspect all completed work in detail at the Nexus Sprint Review. Techniques may be necessary to maximize stakeholder feedback—not to mention to keep them awake. One such technique, or practice, is known as a science fair (also known as “expo” or “bazaar”). More like an informal gathering or meetup than a formal review, these practices can help improve the Nexus Sprint Review by letting stakeholders see what they want/must see, on demand. For more details on running a science fair Sprint Review, read fellow Professional Scrum Trainer Erik Weber’s blog post at www.scrum.org/resources/blog/sprint-review-technique-science-fair.

An offline Sprint Review may also be an option for a large product with numerous stakeholders—especially if they are primarily remote. This practice enables teams to better engage with stakeholders when those stakeholders cannot attend the Sprint Review. You can create short video demonstrations of the Done functionality and share them with your stakeholders to prompt their feedback or entice them to join the Sprint Review.

Nexus Sprint Retrospective

The Nexus Sprint Retrospective is a formal opportunity for a Nexus to inspect and adapt itself and create a plan for improvement. This is key to ensuring continuous improvement. Identical to single-team Scrum, the Nexus Sprint Retrospective occurs after the Nexus Sprint Review and prior to the next Nexus Sprint Planning. The Nexus Sprint Retrospective is an opportunity for improvement for each team as well as the Nexus as a whole.

A Nexus Sprint Retrospective consists of three parts:

• ■   Nexus pre-meeting   Appropriate representatives from the Scrum Teams meet and identify issues that have impacted more than a single team. The purpose is to make shared issues transparent to all Scrum Teams.

• ■   Individual Scrum Team Sprint Retrospectives   Each Scrum Team holds their own, individual Sprint Retrospective—per the Scrum Guide. They can use issues raised at the pre-meeting as input to their team discussions. The individual Scrum Teams should plan experiments to address any issues.

• ■   Nexus post-meeting   Appropriate representatives from the Scrum Teams meet again and agree on how to visualize and track the identified improvements. This allows the Nexus as a whole to adapt.

Because they are common scaling dysfunctions, every Nexus Sprint Retrospective should address the following subjects:

• ■   Was any work left undone? Did the Nexus generate technical debt? If so, why did this happen? How can it be corrected? How can it be prevented?

• ■   Were all artifacts, particularly code, frequently (as often as every day) successfully integrated? If not, why not?

• ■   Was the product successfully built, tested, and deployed often enough to prevent the accumulation of unresolved dependencies? If not, why not?

A retrospective board or other visualization may be helpful to plan and track inspections and adaptations across teams. Using a wiki may not be enough. Having an actionable board may be beneficial. You might want to experiment with the Retrospectives extension found in the Azure DevOps Marketplace. You can see an example of it in Figure 11-2 and learn more about it at https://marketplace.visualstudio.com/items?itemName=ms-devlabs.team-retrospectives.

FIGURE 11-2 The Retrospectives extension helps you visualize inspections and adaptations.

Nexus Artifacts

The Nexus framework introduces additional artifacts to complement the existing artifacts described in the Scrum Guide. These new artifacts provide additional transparency and opportunities for inspection and adaptation at scale.

It’s important to remind you again that there is a single Product Backlog for the entire Nexus. The Product Owner is accountable for the Product Backlog, including its content, availability, and ordering. At scale, the Product Backlog must be understood at a level where dependencies can be detected and minimized. PBIs are often split and refined to a granularity of thinly sliced functionality. PBIs are deemed “ready” for Nexus Sprint Planning when the Scrum Teams can select items to be done with no or minimal coordination with other Scrum Teams.

Nexus Sprint Backlog

In single-team Scrum, the Sprint Backlog contains the Sprint Goal, the forecasted PBIs, and the plan for delivering them. At scale, each team still has their own Sprint Backlog, but the Nexus also keeps and maintains a Nexus Sprint Backlog. The Nexus Sprint Backlog is a composite view of all the forecasted PBIs from the individual Sprint Backlogs of the individual Scrum Teams. It is used to highlight dependencies and the flow of work during the Sprint. It is updated at least daily, often as part of the Nexus Daily Scrum.

The Nexus Sprint Backlog doesn’t show the individual teams’ plans—such as tasks or test cases—only their PBIs. Too much detail would distract from its purpose—to make dependencies transparent so the Nexus can mitigate them. Any visualization of the Nexus Sprint Backlog should show all forecasted PBIs by team and state (for example, to-do, in progress, and done). It should also show dependencies. A manual board is great, but somebody will have to keep it updated.

Unfortunately, Azure Boards doesn’t offer a great board or visualization for the Nexus Sprint Backlog; however, with a bit of process customization, an Azure extension, and a little effort, you can come close. Figure 11-3 shows the results of the following efforts:

FIGURE 11-3 The Query Based Boards extension can display an actionable Nexus Sprint Backlog.

• ■   Further customize the Professional Scrum process, adding a WIP state to the PBI work item type. The new state maps to the In-Progress state category.

• ■   Install the Query Based Boards extension. You can learn more about this extension here: https://marketplace.visualstudio.com/items?itemName=realdolmen.EdTro-AzureDevOps-Extensions-QueryBasedBoards-Public.

• ■   Adopt a PBI naming convention prefixing the title with the team name or initials.

• ■   Create a “Nexus Sprint Backlog” query that returns all PBIs for the current Sprint.

• ■   Set predecessor/successor links accordingly to represent cross-PBI dependencies. These dependencies are typically only cross-team. Cross-PBI dependencies, within the same team, can be managed through that team’s natural execution sequencing—the same as with single-team Scrum.

Nexus Sprint Goal

The Nexus Sprint Goal is an objective for the Sprint. It captures the essence of all the work that the Scrum Teams within the Nexus will perform. Stakeholders will inspect the functionality that the Nexus developed to achieve the Nexus Sprint Goal at the Nexus Sprint Review in order to provide feedback. At the Nexus Daily Scrum, the representatives will inspect progress toward the Nexus Sprint Goal, adjusting their Sprint Backlog and the Nexus Sprint Backlog to reflect their current understanding of the work of the Scrum Teams within the Nexus.

Much like the Sprint Goal for single-team Scrum, the Nexus Sprint Goal gives the Nexus flexibility in developing the scope of what’s been forecasted. That said, the Nexus Sprint Goal is different from a Sprint Goal, because it crosses teams. In that regard, it is probably closer to the single-team Scrum concept of a release goal or a Product Goal.

Tip If it is hard to create a Nexus Sprint Goal, then maybe all that is shared amongst the teams is a codebase? Maybe the teams are not all building a cohesive product. Maybe they shouldn’t be in a Nexus.

The Nexus Sprint Goal is met through the implementation of PBIs by multiple teams. As the Nexus works, it keeps the Nexus Sprint Goal in mind. It gives an individual within a Nexus meaning, purpose, and focus for their specific tasks. When a Nexus has more than 80 Developers, it’s easy for each of them to get lost in the noise. They should keep focused on the big picture. The Nexus Sprint Goal is that big picture.

Integrated Increment

In single-team Scrum, an Increment is a concrete stepping-stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Work cannot be considered part of an Increment unless it meets the Definition of Done.

At scale, there is still the concept of an Increment, but it contains the sum of all integrated work completed by a Nexus. An Integrated Increment must be usable and releasable, which means it must meet the Nexus Definition of Done. The Integrated Increment may itself be integrated into another, larger, working Increment.

Note The Nexus Integration Team is accountable for ensuring that a Done Integrated Increment (the combined work completed by a Nexus) is produced at least once every Sprint.

Definition of Done

A Nexus is based on transparency. All Scrum Teams as well as the Nexus Integration Team work within a Nexus and the organization to ensure that transparency is apparent across all artifacts. They also make the state (for example, integrated or not integrated) of the Integrated Increment transparent. All Scrum Teams in the Nexus should be made aware of integration problems.

Decisions made based on the state of Nexus artifacts are only as effective as the level of their transparency. Incomplete or partial information will lead to incorrect or flawed decisions. The impact of those decisions can be magnified at the scale of Nexus. The product must be developed in a way that dependencies are detected and resolved before technical debt becomes unacceptable. A lack of complete transparency will make it impossible to guide a Nexus effectively to minimize risk and maximize value.

The Definition of Done is applied to the Integrated Increment developed each Sprint. It defines what must be true for the Increment to be integrated, usable, and releasable by the Product Owner. All Scrum Teams of a Nexus adhere to this Definition of Done. Individual Scrum Teams may choose to apply a more stringent Definition of Done within their own teams but cannot apply less rigorous criteria. The Integrated Increment can be considered Done only when the work from each team correctly integrates with the work from all other teams.

Note The Nexus Integration Team is responsible for a Definition of Done that can be applied to the Integrated Increment developed each Sprint. This Definition may be based on existing Definitions of Done, product constraints, and other conventions of the development organization.

As the Nexus improves, it is expected that its Definition of Done will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously Done Increments. The Nexus should inspect that work and adapt a plan for making it Done per the current definition.

Nexus Support in Azure DevOps

The bad news is that there is no first-class support for Nexus in Azure DevOps. The good news is that Nexus is just Scrum, so everything I’ve presented in the book thus far still applies. Only a couple of tweaks are required in order to support multiple teams working on a single Product Backlog. I will call them out in this section.

Configuring Additional Teams

When you create a new Azure DevOps project, a single, default team is created. It has the same name as the project. For example, when I created the Fabrikam project, a “Fabrikam Team” was created. For single-team Scrum, just add the Product Owner, Scrum Master, and Developers to that team and you are good to go. Backlogs, boards, and dashboards are automatically configured for this default team so that the team members can start managing, planning, and executing work.

Tip Azure DevOps allows you to rename the default team. I recommend renaming it to the Nexus Integration Team. Since the Product Owner is a permanent member of the Nexus Integration Team, they will have visibility to all PBIs in the Product Backlog.

Because the Nexus requires a minimum of three Scrum Teams, you’ll be adding teams. Select a short, unique name for each team. You’ll also must select the team members and identify team administrators. I’m a fan of making team members Project Administrators as well—so that Azure DevOps doesn’t block the team. The default behavior is to create an area with the same name as the team. (More on that in a moment.) After creating the teams, you can further socialize the teams by selecting a team logo or avatar. Figure 11-4 shows the Scrum Teams for a medium-sized Nexus along with their respective team images.

FIGURE 11-4 The Teams page lists all the teams in the Nexus.

Each team needs at least one team administrator to be able to configure, customize, and manage the team-related activities. These activities include adding team members and other team administrators, as well as configuring agile tools and team assets. By default, the person who created the team is a team administrator. Naturally, I’m a fan of making all team members a team administrator so that nobody gets blocked by the tool.

Note Don’t confuse team administrator with project administrator. Although both act as a permission container, the team administrator is more focused on managing the agile tools and assets for a team, rather than the project as a whole. Ideally, everyone on the Scrum Team is both a project administrator and a team administrator. To learn more about the team administrator, visit https://aka.ms/add-team-administrator.

Each team gets access to its own suite of agile tools and team assets. These tools, which are listed in Table 11-2, provide teams with the ability to work autonomously while still collaborating with other teams across the Nexus. Each team can configure and customize their own tools to support how they work. These tools reference the team’s default area, iteration, and selected Sprints to filter automatically the set of work items they display. I’ll discuss those settings in a moment.

TABLE 11-2 Team-specific tools and assets.

Planning and tracking	Collaborating	Monitoring and learning
Product Backlog	Team alerts	Analytics by team
Forecasting	Team favorites	Velocity
Epic and feature backlog	Team group filter	Burndown/burnup
Kanban board	Dashboards	Cumulative flow diagram
Sprint Backlog
Taskboard

After creating a new team, the following settings should be configured:

• ■   Membership   Add the Product Owner, Scrum Master, Developers, and any stakeholders to the team. Be sure to give the Scrum Team members project administrator permissions and also make them team administrators. Consider reader (read-only) permission for any stakeholders, unless you trust them making changes to the Product Backlog.

• ■   Team image   Select an awesome avatar or representation for the team. This will up the social experience within Azure DevOps.

• ■   Notifications   Configure any team-level notifications for work items, code (Azure Repos), builds/releases (Azure Pipelines), and artifacts (Azure Artifacts).

• ■   Dashboards   Create a team dashboard with widgets that radiate the information that the team desires.

• ■   Backlogs   Select the backlogs that the team will use (Epics, Features, etc.).

• ■   Working days   Configure which days of the week (for example, Monday through Friday) that the team will be working.

• ■   Default iteration   This iteration is automatically assigned whenever a work item is created from the team context.

• ■   Backlog iteration   This iteration determines which items appear on the team’s backlogs and boards.

• ■   Selected iterations   The iterations selected will appear in the Planning pane in the Backlogs page as well as on the Sprints page (Sprint Backlog and Taskboard).

• ■   Default area   The area is automatically assigned whenever a work item is created. The default area must be one of the areas selected for the team.

• ■   Selected areas   The product areas that this team will develop/look after. The selected areas will determine which items show up on a team’s backlog.

Configuring Areas

Most of the tools in Azure Boards operate using system queries that reference the team’s area settings. For example, a team's default area filters the work items that appear on that team’s backlog. Also, work items that are created using Azure Boards are auto-assigned the areas and iterations based on team defaults. Teams can be associated with one or more areas and include the sub-areas as well.

When introducing the Nexus, the area hierarchy must be updated, to introduce the team areas into the hierarchy. By default, these team areas are created automatically when the teams were created. You can also create new areas manually to represent teams. After the team areas are created, you will want to move existing areas under those teams to establish a hierarchical structure. Drag and drop is your friend. You can see an area hierarchy before (pre-Nexus) and after introducing additional teams in Figure 11-5.

FIGURE 11-5 Adding teams to the area hierarchy to represent ownership of various product areas.

When I created the five teams, I let Azure DevOps create these placeholder areas. They are not required and may even be considered added noise and confusion for some users. For example, business stakeholders, with access to Azure Boards, may wonder about the “Justice League” part of the product. If you want, you can remove those team placeholder areas and just indicate which areas are selected by which team(s). As you can see in Figure 11-6, the list of areas is simpler and less confusing. You can also see that multiple teams are covering the Employees and Tickets areas. I’ll talk about how to do that in a moment.

FIGURE 11-6 Removing placeholder areas results in a cleaner hierarchy.

Whether or not you use pseudo team areas, it’s pretty obvious which team looks after which areas. In practice, however, teams can and do cross over and share areas and Azure DevOps supports this as well. After the areas are configured at the project level, you just select which areas will be used by which team. This is done by going to each individual team’s area configuration and selecting the applicable areas. Multiple areas may be selected, including sub-areas. Also, multiple teams can cover the same area—as was the case with the Employees and Tickets area in our last example. Figure 11-7 shows these two areas selected for the X-Men team. Sub-areas have been included for each area as well. The default area will be assigned to work items that are created from the team context. It must be one of the related areas.

FIGURE 11-7 A team can look after multiple product areas.

Tip If there’s a chance that you’ll add new areas under existing areas in the future, be sure to include sub-areas in order to future-proof the functionality of Azure Boards. If you don’t and a new child area gets added with PBIs, they won’t be visible on your Product Backlog!

Note Initially, individual Scrum Teams may “specialize” in certain product areas. Over time, those teams will improve, learning new domains, technology, and tools. This will allow them to work in increasingly more product areas. Eventually those teams will blossom into feature teams—allowing them to deliver value across many/all areas of the product. As this happens, cross-team dependencies will drop. Someday a team may even be able to get rid of all the team areas and just set their default to the root!

Configuring Iterations

As previously mentioned, iterations support teams who want to plan and track their work. For Scrum Teams, they allow PBI, Task, Test Case, and other work items to be grouped by Sprint. Much like areas, a Nexus defines iterations at the project level and then each team selects the ones they want to be active.

Configuring Sprints with their start and end dates is the same for a Nexus as it is with a single team. I covered this in Chapter 4, “The Pre-game.” With Azure DevOps and Nexus, it is possible to create different Sprint schedules (cadences) for different teams. For example, some Scrum Teams in a Nexus may have a 4-week Sprint whereas others have a 2-week Sprint. If this is the case, you simply define a node under the top project node for each team or cadence (for example, Fabrikam/Titans or Fabrikam/2-Week Sprints), and then define the Sprints under those nodes.

Tip Even though Azure DevOps and Nexus allow teams to have different cadences—different Sprint start dates and lengths—you shouldn’t do this. It will be confusing to know which team is on which Sprint. More importantly, how can the teams plan, execute, and deliver as a cohesive Nexus if the events don’t align? Please weigh all factors before doing this!

After the iterations (Sprints) have been configured at the project level, the individual teams can set a default iteration, set a backlog iteration, and select their active iterations. The iterations selected will appear in the Planning pane in the Backlogs page as well as on the Sprints page (Sprint Backlog and Taskboard). Rather than seeing all Sprints, a team can keep the list of selected Sprints small, possibly only including the current Sprint and a few future Sprints to support their planning horizon.

The default iteration is automatically assigned whenever a work item is created from the team context. For example, if Sprint 3 is selected, then any work items created by this team will have its Iteration set to Sprint 3. The default is @CurrentIteration, which is a macro that always equates to a team’s current Sprint. This macro is not supported on versions of Team Foundation Server older than 2015, or when used in a version of Visual Studio/Team Explorer older than 2015, or when used by Microsoft Excel.

Note As of this writing, when the default iteration is set to the @CurrentIteration macro, PBIs added to the Product Backlog will be assigned to the current Sprint—which is confusing. Though helpful when adding Task work items to the Sprint Backlog or Taskboard, or Test Case work items to the Sprint’s test plan, PBIs added to the Product Backlog should always be set to the iteration root (no Sprint) so that they can be refined and forecasted in a future Sprint Planning. Hopefully, Microsoft will correct this dysfunctional behavior.

Managing the Product Backlog

When viewing the Product Backlog, only PBIs in the areas selected for the team will be displayed. The default team (for example, the Nexus Integration Team) should be able to see all items in the Product Backlog. This is possible because that team’s only selected area is the root and includes sub-areas. It’s important that the Product Owner be able to have a view of the entire Product Backlog.

The other Scrum Teams will only see their PBIs in the Product Backlog. This filtered set depends on which areas are selected by that team. Scrum Teams new to the Nexus may be fairly specialized in their domain and technology capabilities and only be able to work in a few product areas. For example, as you can see in Figure 11-8, the Justice League team’s backlog shows only a subset of the full Product Backlog—just those PBIs with an area of Customers, Employees, or Tickets. Scrum Teams who have improved to the point of being true feature teams may eventually see all PBIs in their backlog—because they are capable of working in any part of the product.

FIGURE 11-8 Each team’s view of the Product Backlog is filtered based on their selected areas.

Tip Can a user be a member of more than one Azure DevOps team? Yes. Should they be? Probably not, unless they are the Product Owner or the Scrum Master of those teams. This is not because it’s difficult or confusing to switch back and forth between backlogs in Azure Boards, but more about the drop in focus when a Developer jumps from team to team. As I’ve said before, growing long-lived teams of full-time, dedicated team members is preferable.

Chapter Retrospective

Here are the key concepts I covered in this chapter:

• ■   Nexus   A relationship or connection between people or things.

• ■   Nexus framework   A framework, similar to Scrum, 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. The Nexus framework can be considered an “exoskeleton” to the Scrum framework, allowing it to scale.

• ■   Scaled Professional Scrum   Scrum.org’s instantiation of the Nexus framework. Scaled Professional Scrum includes more than 40 complementary practices for scaling Scrum. You can see that list here: www.scrum.org/scaled-professional-scrum-nexus-practices.

• ■   Nexus Integration Team   A new role that exists to coordinate, coach, and supervise the application of Nexus and the operation of Scrum so that the best outcomes are derived. The Nexus Integration Team is a Scrum Team and, thus, consists of the Product Owner, a Scrum Master, and three or more Developers.

• ■   Refinement   Similar to single-team Scrum but even more important at scale so that dependencies, especially those involving more than a single team, are identified and removed or minimized. Refinement is a required event in Nexus.

• ■   Nexus Sprint Planning   Similar to single-team Scrum but even more important at scale to coordinate the high-level activities of all Scrum Teams. Sprint Planning occurs as a whole as well as for each team within the Nexus Sprint Planning event.

• ■   Nexus Daily Scrum   A Daily Scrum pre-meeting in which appropriate Developer representatives from each Scrum Team inspect the current state of the Integrated Increment and identify integration issues or newly discovered cross-team dependencies or cross-team impacts. The Daily Scrum occurs for each team after the Nexus Daily Scrum.

• ■   Nexus Sprint Review   Similar to single-team Scrum, a review held at the end of the Sprint to allow stakeholders to provide feedback on the Integrated Increment and to adapt the Product Backlog if needed. The Nexus Sprint Review replaces the need for individual Scrum Team Sprint Reviews.

• ■   Science fair   A Sprint Review technique that enables many stakeholders to inspect just the Done functionality that they are interested in. The science fair is an informal gathering, much like a meetup, and is also known as an “expo” or a “bazaar.”

• ■   Nexus Sprint Retrospective   A formal opportunity for a Nexus to inspect and adapt itself and create a plan for improvement to be enacted during the next Sprint to ensure continuous improvement. The Sprint Retrospective occurs for each team within the Nexus Sprint Retrospective.

• ■   Nexus Sprint Backlog   A composite view of the PBIs from the Sprint Backlogs of the individual Scrum Teams. The Nexus Sprint Backlog is used to highlight dependencies and the flow of work during the Sprint. It should be updated at least daily.

• ■   Nexus Sprint Goal   An objective set for the Sprint. It is the sum, aggregate, or theme of all the work and Sprint Goals of the Scrum Teams within the Nexus. The Nexus Sprint Goal should be shared with all members of all teams to be used as a guiding light during development.

• ■   Integrated Increment   Represents the current sum of all integrated work completed by a Nexus. The Integrated Increment must be usable and releasable, which means it must meet the Definition of Done. The Integrated Increment is inspected at the Nexus Sprint Review.

• ■   Definition of Done   Similar to single-team Scrum but even more important at scale because it is applied to the Integrated Increment developed each Sprint. Individual Scrum Teams may choose to apply a more stringent Definition of Done within their own teams, but they cannot apply less rigorous criteria. All Scrum Teams of a Nexus adhere to this common Definition of Done.

• ■   Team Areas   Determine which PBIs appear on the team’s backlog and Kanban board. Teams can select one or more areas and an area can be selected by more than one team. The default team is where the Product Owner will primarily hang out and should have the root area selected, including sub-areas to see all PBIs in the Product Backlog. Some Nexus rename this default team to the Nexus Integration Team.

• ■   Feature teams   A long-lived, cross-functional, cross-component team that can complete many/all end-to-end customer features. Feature teams will have many team areas selected—indicating that they can work in all of those product areas. High-performance feature teams may have one single area selected—the root, including all sub-areas.