Home > Articles

  • Print
  • + Share This
This chapter is from the book

Nexus Artifacts

Artifacts capture the results of work performed. They also provide transparency and opportunities for inspection and adaptation.

Product Backlog

There is a single Product Backlog for the entire Nexus and all of its Scrum Teams. Since a Nexus is organized a single product, it only has a single Product Owner, and that single Product Owner maintains a single Product Backlog. All teams pull work from this single artifact.

Nexus Goal

During the Nexus Sprint Planning meeting, the Product Owner discusses a goal for the Sprint. This is called the Nexus Goal. It is the sum of all the work and Sprint Goals of the individual Scrum Teams within the Nexus. The Nexus should demonstrate the functionality that it developed to achieve the Nexus Goal at the Nexus Sprint Review.

Nexus Sprint Backlog

The Nexus Sprint Backlog contains the PBIs that have cross-team dependencies or potential integration issues. It does not contain PBIs that have no dependencies, nor does it contain tasks from the individual Scrum Team Sprint Backlogs. 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.

Integrated Increment

The Integrated Increment is the integrated aggregation of all work completed by all the Scrum Teams in a Nexus. The Integrated Increment must be usable and potentially releasable, which means it must meet the definition of “Done” agreed to by the Development Team. The Product Owner is a key stakeholder for it and defines the quality criteria that the Product Increment must meet. The Integrated Increment is inspected at the Nexus Sprint Review.

Artifact Transparency

Just like Scrum, on which it builds, Nexus is based on transparency. The NIT works with the Scrum Teams in the Nexus, and the broader organization, to ensure that all Scrum and Nexus artifacts are visible and that the state of the Integrated Increment can be easily understood.

Decisions made based on the state of Nexus artifacts are only as effective as the level of artifact transparency. Incomplete or partial information will lead to incorrect or flawed decisions, making it difficult or impossible to guide the Nexus effectively to minimize risk and maximize value.

The greatest challenge a Nexus faces is detecting and resolving dependencies before technical debt accumulates to an unacceptable level. The test of unacceptable technical debt is when the Nexus tries to integrate the work from its Scrum Teams. When that integration fails, the unresolved dependencies remain hidden in the code and test base, lowering or negating the value of the software.

Definition of “Done” in Nexus

The NIT 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.”

The Increment is done only when it has been determined to be usable and potentially releasable by the Product Owner. A PBI can be considered done when that functionality has been successfully added to the product and integrated into the Increment.

All Scrum Teams are responsible for developing and integrating their work into an Increment that satisfies these attributes. Individual Scrum Teams may choose to apply a more stringent definition of “Done” within their own teams, but they cannot apply less rigorous criteria than agreed for the Increment.

  • + Share This
  • 🔖 Save To Your Account