What are Scrum Artefacts?

Product Backlog

A Product Backlog contains elements with which a Product Goal defined by the Product Owner – the product objective – can be achieved. The Product Goal thus ensures that “only” items that contribute to the development goal are recorded.

The Product Owner is responsible for both the Product Backlog and the Product Goal. In the course of continuously refining and prioritising the items, he or she uses the opinions of stakeholders and the expertise of the developers (who are also allowed to record backlog items). He/she communicates the product backlog items, ensures transparency and understanding and goes into sprint planning with a pre-selection of items – also known as the Selected Backlog.

Interestingly, the Scrum Guide² only talks about Product Backlog Items without naming them more precisely. User stories, epics, features, requirements etc. are not explicitly mentioned. In practice, it is above all the Backlog Refinement³ and thus the repeated prioritisation of the items that are important, since the content is very dynamic; new content is added regularly and the stakeholders change their opinion in the course of a development, which can have a direct impact on the prioritisation.

Sprint Backlog – the plan for the current Sprint

The Sprint Backlog is the plan for the current Sprint. It is agreed in the Sprint Planning and contains all Product Backlog Items, which are selected by the Developers for the current Sprint and implemented in the Sprint. In addition, the Sprint Backlog contains the Sprint Goal, to which the Developers jointly commit, and the tasks that are necessary to realise the items and achieve the goal.

After the Product Owner has explained the “why” of the Sprint and the most important items from his point of view, the Developers decide “what” is included in the Sprint and “how” it will be implemented. They are thus responsible for the Sprint, the Sprint Goal and the Sprint Backlog. Ideally, they select the items with the highest priorities, which the Product Owner has defined together with them and on behalf of the most important stakeholders in the course of the Backlog Refinement. The tasks for realising the individual items should not take more than one day, so that tasks can be completed every day. The progress within the Sprint can be visualised with taskboards or burn-down charts, for example.

Increment – the result of all Sprints completed

An Increment comprises all Backlog items completed during a Sprint and includes the Increments of all previous Sprints. At the end of a Sprint, the new increment must be “Done”, i.e. it must be in a usable state and meet the Definition of Done. In addition, the Increment must be “potentially shippable”, i.e. it must work, it must be tested, it must be able to be put into operation, it should be documented and it should offer added value to the users. Several Increments per Sprint are also possible.

In practice, not every completed Increment is made available to the customers, as this could overwhelm many customer organisations. In the case of an app that updates itself automatically in the background on a mobile phone, one delivery per month is quite conceivable, but in the case of an application that is operated company-wide with several thousand users, this would possibly generate too much effort. Here, marketing and sales are called upon to define a sensible release strategy together with the Product Owner.

Scrum Artefacts and commitments

The current Scrum Guide emphasises the importance of commitments in the course of the artefacts. As a self-commitment, the commitment corresponds to one of the Scrum values. Broken down to the individual Scrum artefacts, there are three direct assignments:

• The Product Goal is the commitment for the Product Backlog.
• The Sprint Goal is the commitment for the Sprint Backlog.
• And the Definition of Done is the commitment for the Increment.

These commitments serve to reinforce empiricism and the Scrum Values for the Scrum Team and its stakeholders. The Product Goal corresponds to the team’s long-term development goal, which they should achieve through their daily work. The Sprint Goal is the single objective for a specific Sprint. And the Definition of Done is a formal description that captures quality characteristics for an Increment.

Impulse to discuss:

How can we succeed in permanently scheduling a reasonable amount of Backlog items in the Sprint Backlog, especially when planning efforts is always difficult in practice?

Notes:

[1] What is a backlog and what types exist?
[2] see Scrum Guide here and here respectively
[3] How does a Backlog Refinement work?

Here you can find a German podcast about the often misunderstood incremental development in Scrum.

And here you will find additional information from the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.