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, which we introduce to you 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 are the three process documents the Product Backlog, which is described in detail in this chapter, as well as the Sprint Backlog and the Increment. The Scrum Artefacts help the Scrum Team to get an overview of the work(s) or value(s). 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 that is necessary for the development of the final product. These entries are also called Product Backlog Items. They include features, functions, requirements, but also 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 down in "prose" by the Product Owner or his stakeholders. They don't make any 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).
What about Scrum of Scrums?
When more than one Scrum Team is working on a project or product release, the teams use 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 according to their 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 to be 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. But other criteria can also play a role, such as development costs, the value estimate, or risks.
The Kano model can also be used as a tool for decision-making.
If new insights are gained during the project, so that a re-prioritisation becomes necessary, this can be demanded by the Product Owner at any time. This leads to a change in the previous prioritisation.
The Kano Model¶
The Kano model graphically represents the relationship between customer satisfaction and the 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 a matter of course and 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 found out by observing the market.
- satisfy customers when they are provided.
- make customers dissatisfied if they are not provided.
- Attractive attributes:
- are not a matter of course and customers do not demand these features.
- do not make customers more 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: further tasks, user stories, Epics, and Themes. Epics are very extensive user stories that are still too big for a user story at the time of their evaluation as an Epic. Themes are different user stories that are grouped into a common topic area.
As soon as these entries are moved to the upper area of the Product Backlog, they have to 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 Definition of Done and has been approved by the Product Owner, it can be considered complete.
Commitment: The Product Goal¶
The development compass¶
The Product Goal is the Scrum Team's commitment to the Product Backlog and serves as a compass for the development of the current project. Unlike (previously) the Product Vision, it describes a concrete goal that is pursued with the Scrum project and generated by 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 serve the marketing of the product and its economic success.
This involves the following questions:
Backlog Refinement¶
The Product Backlog should be evaluated and reviewed regularly. 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 suitable for updating the Product Backlog.
Backlog Refinement Meeting¶
Although the Backlog Refinement Meeting is mentioned in the figure "Attendances of Scrum Meetings" in the previous chapter, this meeting is not an official Scrum event prescribed by the Scrum Guide. In practice, however, it makes sense not to forego 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 jointly examined. 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 boundary conditions and entries or user stories that have been identified as unimportant for the product are removed from the Product Backlog.
Following topics can be used as an agenda for the Backlog Grooming 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 (effort estimation)
- If necessary, schedule releases
The Product Owner is responsible for the Backlog Refinement Meeting in his role as manager of the Product Backlog. He is 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 implemented without being necessary.