What is a Backlog?

Backlog Definition

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. [1] The following items can be distinguished:

• functional and quality requirement
• epic
• user story
• job story
• use case
• use case slice
• impediment

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.

Product 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. It can be described by four properties:

• Prioritisation: The 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.

Release Backlog

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, while requirements with priorities of 801 and lower are moved to later releases.

Sprint Backlog

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 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 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.
• With the Relative Weight Method, each 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.
• 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.

Tips for Working with Backlogs

There are a number of tips for 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 refinement or grooming. [3] It ensures a high level of transparency so that all project participants always know what is currently being worked on and what is coming up soon. At the same time, companies can react quickly and flexibly to changes.
• The so-called 5S technique promises help in the organisation and maintenance. In Japanese, the S stands for Seiri, Seiton, Seiso, Seiketsu and Shitsuke, in English for Sort, Set in Order, Shine, Standardize and Sustain. [4]
• In practice, working with user story mappings has proven to be a useful complement to working with backlogs.
• In numerous publications, backlog items are equated with user stories. This may make sense for later implementation, but for content-related work, grouping on the basis of epics or features can be very useful.
• As the size of backlogs grows quickly, it can be useful to identify items that can be deleted.
• When prioritising, it makes a lot of sense to define absolute values per item so that there are no two items that have the same priority.
• According to the Scrum Guide, the Product Owner is responsible for sorting the Product Backlog items. At the same time, he is allowed to delegate this task, as long as he keeps the responsibility. Sorting in the team ensures transparency at an early stage and an increased understanding of those involved.

You can find more tips in the two-part blog series Boost your Backlog.

Backlogs in Practice

There is a list of questions in the context of backlogs. You can find answers to some of the questions in our blog or in our Smartpedia section:

• How can items be estimated with the Team Estimation Game?
• How does Planning Poker work?
• What is a Definition of Ready?
• What contents belong in a Definition of Done?
• What to do when backlogs are glorified?
• What are the responsibilities of the Product Owner in relation to backlogs?
• How can a backlog help teams to learn in agile projects?

We are sure you can think of more questions. Feel free to contact us and we will try to answer your questions or publish relevant articles.

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?

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

[1] The Scrum Guide deliberately refers to Product Backlog Items (PBI) because it wants to use generic, universal terminology that can be used in different contexts and for different types of projects. If, for example, the guide were to limit itself to User Stories, this could give the impression that Scrum is only suitable for software development projects or that teams would be forced to use the User Story format. The general term PBI avoids such misunderstandings.

[2] Interestingly, the Scrum Guide mentions the term Product Backlog Item (PBI) 13 times, but does not mention the term Sprint Backlog Item at all, although the PBI becomes a Sprint Backlog Item when it is scheduled in the Sprint Backlog.

[3] “Backlog grooming” or “Scrum grooming”, which are relatively common in German-speaking countries, are almost no longer used in English-speaking countries because grooming is a so-called trigger word with a very negative sexual connotation. We therefore deliberately use Refinement.

[4] Here you can find more information on the 5S technique.

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.

Here you can find a video about the creation of a product backlog.

And here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.