What ist a backlog, what types exist, how are they created and prioritised?
Backlog is a term meaning “an accumulation of something, especially uncompleted work or matters that need to be dealt with.” Or to put it simply: It is a list of tasks or requirements that need to be done. And to backlog something means to stockpile something or put it aside for later use.
In software and product development and in agile project management, different types of entries are managed in backlogs. These are called backlog items. The following items can be distinguished:
- functional requirement
- quality requirement
- user story
- job story
- use case and use case slice
Ideally, each item should contain a description, a priority, an effort estimate and a customer benefit. The higher the priority of an item, the more precisely it is specified in practice. At the same time, the priority increases the probability that it will be processed or realised.
Types of Backlogs
The organisation of backlogs is structured differently in various companies. Often there are three types of backlogs:
- Product Backlogs,
- Release Backlogs and
- Sprint Backlogs.
If different teams are involved in a development, it is a good idea to work with team backlogs and distribute the items accordingly among the respective teams. If only one team is involved, then Release and Team Backlog are identical. Developers and employees can also maintain individual, personal lists.
The current Scrum Guide 2020 only knows the two terms Product and Sprint Backlog.
The Product Backlog is the first container in which tasks to be completed, functional requirements, features etc. are recorded. In some organisations it is also called domain backlog – whenever organisations are active in different domains and it makes sense to record the items per domain. A product backlog can be described by four properties:
- Prioritisation: The backlog items are prioritised.
- Detailing: A item is described in detail the higher its priority is.
- Estimation: An effort estimate is performed for each item. The higher the priority, the more accurate the estimate.
- Evaluation: A item describes a customer benefit and this affects the prioritisation of the item.
The prioritisation of product backlog items is essential. Not all requirements are equally important, have the same customer benefit or cause the same effort for implementation. For example, prioritisation is carried out in Scrum by the product owner – ideally in close cooperation with the developers. The product owner is the contact person for the relevant stakeholders. While stakeholders often evaluate requirements with a view to a business value, the team pays attention to the development effort and a technically meaningful order of implementation. The use of relative values with Fibonacci figures is a good way of estimating costs. This has the advantage that expenses on a small scale can be estimated very precisely at the daily level (1 day, 2 days, 3 days, 5 days etc.), expenses on a large scale relatively roughly (e.g. 20 days, 40 days, 100 days etc.).
It should be noted that prioritisation must be carried out again and again because new requirements or the refinement of existing items add new insights. A product backlog is therefore very dynamic and thus differs significantly from a requirement specification.
Agile projects are divided into releases and iterations. Since the duration of these iterations in Scrum, for example with a recommended duration of one week to a maximum of one month, is relatively short, they are called Sprints. They always have the same duration in a project. A defined number of sprints results in a release. Each company has to define both – duration and quantity – for itself. Example: After five sprints, there is the first release, after five more a next release, and so on. If there are several teams and parallel sprints, the intervals should be coordinated. Requirements are assigned to releases based on their priorities. Defining priority limits helps to distribute requirements to releases. If the product owner determines a lower limit of 802, then the items of the product backlog with priorities of 802 and higher are moved to the next release backlog, while requirements with priorities of 801 and lower are moved to later releases.
In each Sprint, a functional, potentially deliverable intermediate product – a so-called increment – is to be developed. The sprint planning meeting decides which requirements from the product or release backlog are to be implemented in the next sprint. Requirements are to be implemented. The team selects the user stories with the highest priorities and estimates which and how many can be implemented within the next interval. The items to be implemented end up in the sprint backlog. The user stories are then divided into tasks that can be completed within one day. The development team independently determines who realises the tasks. In order to recognise the progress of the development, it is important to provide the tasks and subsequently the user stories with states. Once all tasks for the realisation of a user story have been completed, it is considered as realised. Taskboards or a user story mapping can be used for visualisation.
Prioritisation of Backlog Items
Prioritising backlogs is an important success factor for software and product development, as it ensures that the important and correct requirements are realised. There are various methods for prioritising which can also be combined with each other:
- The Kano Model
The Kano Model classifies five characteristics that contribute to customer satisfaction in different ways: basic, performance and enthusiasm characteristics, as well as insignificant characteristics and rejection characteristics. Basic characteristics generate dissatisfaction when they are missing. Performance characteristics are an important factor for customer satisfaction and differentiation from the competition. And enthusiasm characteristics lead to disproportionate satisfaction.
- The MoSCoW Method
The MoSCoW Method distinguishes between functions that the development team should absolutely implement and those that could be implemented:
Must: Must-have functionalities that need to be implemented.
Should: Functionalities that have to be implemented after the must-have.
Could: Functionalities that can be implemented if they do not interfere with must-have or should functions.
Won’t: Functionalities that should not be implemented.
- Relative Weight Method
With the Relative Weight Method, each backlog item in the categories Advantages, Penalties, Risks and Costs is rated with a number from 1 to 9. The questions about the advantages (how big would the advantage be if a requirement were realised) and the penalties (how big would the penalty be if the requirement were not realised) are evaluated by the product owner together with the relevant stakeholders. And the questions about the risk (how high are implementation risks and dependencies on other teams and developments) and the costs for implementation are discussed by the product owner with his development team. The values for benefits and penalties are then divided by the values for risks and costs. The results are the basis for the prioritisation.
- Theme Screening
In Theme Screening, you identify up to nine evaluation criteria and then select a Baseline Theme, i.e. a user story that serves as the basis for a relative evaluation. It is recommended to select a backlog item that is familiar to the development team and should be implemented soon. You then rate the items in the evaluation criteria as plus, minus or zero in relation to the baseline theme. Prioritisation is achieved by adding the plus and subtracting the minus values per item.
There are other methods like Rocks, Pebbles & Sand, Walking Skeleton or Theme Scoring. Which method is best suited for prioritising backlogs cannot be answered in general. Each company should make its own decision.
Continuous Working with Backlogs
Backlogs are dynamic. New features, user stories or defects are added and stakeholders change their wishes. This results in new priorities on an ongoing basis. Regular maintenance is called backlog refinement or backlog grooming*. It ensures a high level of transparency so that all project participants always know what is currently being worked on and what will be done soon. At the same time, companies can react quickly and flexibly to changes. In practice, working with user story mappings has proven to be a useful addition.
Impulses to discuss:
Even though the Scrum Guide does not know any release backlogs, many organisations consider them very useful. Is the term missing from your point of view?
And: What is the typical age of a product backlog item?
* “Backlog Grooming” or “Scrum Grooming”, which is often used in German-speaking countries, is less used in English-speaking countries. Until about 10 years ago, grooming was understood as care, with which, for example, horses or dogs were very carefully combed. Since then the meaning has shifted and grooming is linked to the thought of adults approaching children. We therefore consciously use Refinement.
Under the keyword “lifelong learning” more and more people recommend to dedicate more time to personal learning. The term “learning backlogs” is also used in this context.
Recommendations from practice can be found in the article: Boost your backlog.
Here you can find a video about the creation of a product backlog.
And here you will find additional information from our Smartpedia section: