Scrum Guide and Scaling: Part 4 - Scrum Artifacts

• Scrum Guide and Scaling: Part 1 - Scrum Theory
• Scrum Guide and Scaling: Part 2 - Scrum Teams
• Scrum Guide and Scaling: Part 3 - Scrum Events
• Scrum Guide and Scaling: Part 4 - Scrum Artifacts

Such a grouping attribute is useful for filtering the Product Backlog in different scenarios:

• During the estimation process by an appropriate development team;
• During the Sprint Planning to make clear the team division;
• In general, to mark Product Backlog items that belong together.

4.2 Sprint Backlogs

As already described in the section Sprint Planning (Part 4.2.2) development teams develop and update their work plan for the next Sprint in the form of a Sprint Backlog. As a rule, each development team works with its own Sprint Backlog in their daily Scrum, as can be inferred from this quote:

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.

Can not there be a common Sprint Backlog for all Development Teams? This could increase the complexity of the coordination, on the other hand it could provide greater transparency with respect to the common supply. The Scrum Guide says nothing about it. The Sprint Backlog consists of the Product Backlog items selected for the current Sprint as well as the implementation plan of the team. If the Development Teams decide to have a common implementation plan, they are responsible for that. The challenge of the Scrum Master is therefore to present alternatives to the team and to support the self-organized work in alignment with other development teams and the Product Owner.

4.3 Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”

If multiple Scrum Teams work on a product, then the rules for this product organization apply for them as they do for a single Scrum Team. This means in particular that the Product Owner gets a single - thus fully integrated -  Increment at the end of a given Sprint.

It is quite possible that some aspects of the product Increment will be reviewed with the respective Development Teams in a scaled version of the Sprint Review. Despite this, there is only one product in a product organization according to Scrum, and after each Sprint, there is an Increment of this product in potentially deliverable state.

4.4 Artifact Transparency

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

There is actually nothing to add. In the truest sense of the word. Each artifact that is used beside the inherent Product Backlog, Sprint Backlog, Increment and one or the other progress-reporting slows down the Scrum team. This does not automatically mean that you should forego any additional documents. If the value of an artifact exceeds its cost, it can well be introduced by a product organisation.

By the way: artifacts should not be confused with product components, such as operating manual or online help. Such product components are, inter alia, included in the definition of „Done“ or recorded in the Product Backlog as delivery items.

4.5 Definition of „Done“

A seemingly paradoxical rule for the definition of „Done“ for multiple Scrum Teams can be derived from the Scrum Guide:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency.

Does this mean to establish a common definition of "Done" for a number of Scrum Teams, or not? In principle, all Scrum Teams working on the same product follow the same definition of "Done". However, there are cases in which a particular Scrum Team has a different, usually more extensive definition of "Done" as a benchmark. This is especially true if other documentation or testing requirements are applicable in a product area. Especially in this case, it is important for the product organisation to ensure that the different levels are known to all who work on the product - for example, to prevent an incorrect assessment of the performance of the team in question.