Skip to content

Theory "Product Backlog"

What is the Product Backlog?

At the beginning of the project, the Product Backlog is created. The Product Backlog is the first Scrum Artefact we introduce in this chapter.

What is a Scrum Artefact?

Scrum is not a method, but a framework. Within this framework, there are three relevant elements: the roles in Scrum, which you already know from the previous chapter; the meetings in Scrum, which you will come across again and again throughout a Scrum project; and the Scrum Artefacts. The Scrum Artefacts consist of three process documents:

  1. the Product Backlog, which is described in detail in this chapter,
  2. the Sprint Backlog, and
  3. the Increment.

The Scrum Artefacts help the Scrum Team to get an overview of the work or value. Each Scrum Artefact has a commitment to which the Scrum Team is committed and which creates transparency.

The Product Backlog is the central collection of requirements for the product from the customer's point of view. It is therefore the responsibility of the Product Owner.

It contains every entry necessary for the development of the final product. These entries are also called Product Backlog Items. They include features, functions, requirements, as well as corrections, representations, or even user interfaces (GUI - Graphical User Interfaces).

A frequently used form of entry is a so-called User Story

User Stories are wishes and requirements for a final product that are written in plain language by the Product Owner or stakeholders. They make no reference to how the features are to be technically implemented — this comes later in the Sprint Backlog.

The Product Backlog

  • is the responsibility of the Product Owner.
  • contains a list of the desired functionalities.
  • may contain User Stories as an essential component.
  • contains entries that are prioritised and estimated (e.g., business value contribution, importance). Top-priority entries will be processed in the next Sprint.
  • is refined during the project, if there is reason to do so, according to the Product Owner's specifications.
  • is subject to constant change and is the centre of agile adaptation. It should be updated at least once before each Sprint Planning Meeting.
  • should meet the DEEP criteria (detailed appropriately, estimated, emergent, prioritised).

Fig. 3.1: What does DEEP stand for?

What about Scrum of Scrums?

When more than one Scrum Team is working on a project or product release, the teams share a common Product Backlog, and each team is assigned a Sprint Backlog. At the end of each Sprint, the work of the individual teams is brought together in the common Product Backlog.

Prioritisation

Once the initial set of requirements has been identified, the next step is to prioritise the entries in the Product Backlog, i.e. to rank them by importance. Entries listed higher up in the Product Backlog are more detailed and precise than entries listed lower down. Furthermore, it is a good idea to rank User Stories that are easier to implement higher in the Product Backlog. User Stories that are more complex to implement are therefore found further down in the Product Backlog.

The top entries are the PBIs that the Product Owner wants to have implemented first. The criterion for prioritisation is usually the business value contribution that the implementation of the respective User Story delivers. However, other criteria may also play a role, such as development costs, value estimates, or risks.

The Kano model can also be used as a tool for decision-making.

If new insights are gained during the project and re-prioritisation becomes necessary, the Product Owner may request this at any time. This leads to a change in the previous prioritisation.

The Kano model

Fig. 3.2: The Kano model as a decision-making tool for prioritisation.

The Kano model graphically represents the relationship between customer satisfaction and realised quality. Customer satisfaction ranges between "low" and "high," and quality can be represented on a scale between "not fulfilled" and "realised." In the Kano model, there are three central characteristics:

  • Basic attributes:
    • are taken for granted by the customer.
    • do not make customers more satisfied if they are provided.
    • make customers disproportionately dissatisfied if they are not provided.
  • Performance attributes:
    • are actively demanded by the customer.
    • can, for example, be identified by observing the market.
    • satisfy customers when they are provided.
    • make customers dissatisfied if they are not provided.
  • Attractive attributes:
    • are not taken for granted and customers do not demand these features.
    • do not make customers dissatisfied if they are not provided.
    • make customers disproportionately satisfied if they are provided.

Product Backlog Items

In each Sprint, i.e., in each development cycle, a number of the top entries from the Product Backlog determined by the Developers are converted into an Increment. Therefore, the entries or User Stories in the upper area must be designed in such a way that their implementation is possible in the short Sprint cycles.

Further down in the Product Backlog there are entries of various sizes: tasks, User Stories, Epics, and Themes. Epics are very extensive User Stories that are still too large to be implemented as a User Story at the time of their evaluation. Themes are different user stories that are grouped into a common topic area.

Fig. 3.3: Exemplary structure of a Product Backlog, incl. User Stories, Epics and Themes.

As soon as these entries are moved to the upper area of the Product Backlog, they must be broken down into smaller entries or User Stories to ensure their feasibility.

When an entry is transferred to technical implementation, it is removed from the Product Backlog, and the entries listed further down move up. Tasks that meet the Definition of Ready and fit the Sprint Goal are ready to be moved into the Sprint Backlog. The Product Backlog changes continuously.

As soon as an entry from the Product Backlog meets the so-called Definition of Done and has been approved by the Product Owner, it can be considered complete.

To express it less technically

Tasks that the Developers deem understood (= Definition of Ready) and that fit the goal of the current Sprint (= Sprint Goal) are processed in the next Sprint. For this purpose, they are transferred to the so-called Sprint Backlog. If the tasks at the end of the Sprint correspond to what was previously agreed (= Definition of Done), then they are considered completed.

Commitment: The Product Goal

The development compass

The Product Goal is the Scrum Team's commitment to the Product Backlog and acts as a compass for the development of the current project. Unlike the (previously used) Product Vision, it describes a concrete goal that is pursued with the Scrum project and achieved through the Sprints.

Customers and users should be involved as much as possible in the development of the Product Goal. The Product Owner develops a common understanding of the goal for the stakeholders of the project and defines the framework conditions that support the marketing of the product and its economic success.

This involves the following questions:

Fig. 3.4: Questions to ask when developing the Product Goal.

Backlog Refinement

The Product Backlog should be regularly evaluated and reviewed. This evaluation and review allow the entries in the Product Backlog to be examined and checked to see whether they are still up to date and whether they correctly reflect the interests of the customer. The Backlog Refinement Meeting is appropriate for updating the Product Backlog.

Backlog Refinement Meeting

Although the Backlog Refinement Meeting is mentioned in the figure "Attendance of Scrum Meetings" in the previous chapter, this meeting is not an official Scrum event defined in the Scrum Guide. In practice, however, it makes sense not to omit this meeting, because it allows the later Sprint Planning Meeting to be conducted more efficiently.

As the name of the Backlog Refinement Meeting suggests, this is where the Product Backlog is refined and maintained. The Scrum Team comes together and the Product Backlog is examined collaboratively. Existing entries in the Product Backlog are reviewed and prioritised. During this meeting, the contents are further specified and their effort is estimated. New entries and User Stories are derived from the previous results and findings. The prioritisation is updated due to changing circumstances, and entries or User Stories that have been identified as unimportant for the product are removed from the Product Backlog.

The following topics can be used as an agenda for the Backlog Refinement Meeting:

  • Sorting and prioritising the Product Backlog Items
  • Deleting entries that are no longer important
  • Adding new entries to the Product Backlog
  • Formulating and adding details to Product Backlog Items
  • Summarising Product Backlog Items
  • Estimating entries in the Product Backlog (estimation of effort)
  • If necessary, scheduling releases

The Product Owner is responsible for the Backlog Refinement Meeting in their role as manager of the Product Backlog. They are supported by the Developers. This ensures that the Product Owner has the same level of knowledge as the Developers. Furthermore, this cooperation increases the motivation of the team, as correlations are better recognized and unimportant User Stories are deleted from the Product Backlog before they are unnecessarily implemented.