Scrum Guide and Scaling: Part 4 - Scrum Artifacts
Scrum artifacts or process documents provide guidance or links in the process framework.
4.1 Product Backlog
The Product Backlog is the core artifact of Scrum. In larger organizations management of the Product Backlog is unnecessarily complicated. What are the key messages, what are the rules for a Product Backlog, which also apply in scaled environments?
First of all, there is only one product backlog. For this there is a very clear statement in the Scrum Guide:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. […,] Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
- 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.
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.
About the author
Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.
Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.
- Experienced ScrumMaster, Product Owner, Coach and Trainer
- Introduced Scrum at WEB.DE
- Coaching of internationally distributed teams
- Transition from RUP to Scrum at UOL Brazil
- Scrum Trainings and Coaching in Germany, Switzerland and Austria
About the author
Peter has set himself the task of creating companies that deliver value for their customers and employees. That was also the motivation behind his decision to found DasScrumTeam. Peter is a passionate Scrum Trainer (Certified Scrum Trainer, CST) and consultant with a solid background in engineering. Since 2007, he has trained and advised a wide range of development teams, specialist departments, project managers and those in leadership positions, helping them to apply the Scrum framework, agile planning methods and software engineering practices. Peter is a graduate engineer (Dipl.-Ing, TU) specialising in electrical engineering and information technology.
- Experience with Scrum since 2004 as Team member, Scrum Master, Product Owner, Coach and Trainer.
- Served as ScrumMaster in internationally distributed Scrum Teams
- Co-founder and Product Owner at DasScrumTeam AG
- Key interests: Agile companies and Scrum beyond Software