How does working with backlogs look like in practice? See for yourself!
Scrum primarily differentiates between a product backlog, a release backlog and a sprint backlog.
A backlog is initally a list of requirements
that the team has to process.
The product backlog (sometimes called the domain backlog: normally when there is one backlog per domain) is the core of a Scrum project because it collects requirements that the software has to fulfil. That could be functions or bugs, for example, that the team should implement or fix. Normally so-called user stories are used in order to describe these requirements. That means, for example, that a new function from the view of the target group would be defined:
“As a visitor to this website, I would like to be able to use a search feature with which I can search the entire site and quickly find answers to my questions.”
Not all requirements are equally important or strenuous: they get a prioritization and an estimate of the effort they will take, and through these they are either implemented as soon as possible or put off until later. This task deals with the development team together with the so-called product owner, the representative of all the project’s stakeholder: whilst the priorities of the requirements are weighed up based on typical factors like the value of the business, the developers evaluate the effort of implementation. These estimates normally don’t produce absolutes, like ‘this requirement will take four person-days.’ Instead, they are given a relative value, like a Fibonacci number: a requirement with an effort of 2 is more quickly dealt with than one with a 5. At the end, there is a list in which the requirements are sorted according to their priorities.
If a project includes multiple teams, the tasks can be allocated to each team and then team backlogs can be created from them. If there is only one team, then the product backlog corresponds to the team backlog.
There are different types of backlogs. What the individual
backlogs contain and how they can be used well and by whom –
Businesses have to answer these questions.
Prioritizing – but what is the best way?
Comprehensive projects create comprehensive backlogs – and it is not always clear which requirements are the most important or how they can be evaluated in comparison to others. That’s why there are methods that make prioritizing easier. For example, with the help of the Kano Model, features are classified as base factors, performance factors or enthusiasm factors. This classification is based on a survey of the users:
Are there features that a user expects in a certain context? Formatting options in a text editor, for example? Then this feature has a high base factor and has to be implemented. If it concerns an additional feature in order to expand the product, then the requirement has a high performance factor. If it’s just a small improvement, or decoration, then the feature can get the users enthused. This is how the developers and the product owner know which requirements they should prioritize in the current project context.
The MoSCoW principle is a similar process. Because it differentiates between, amongst other things, features that developers should definitely implement and ones that just could be implemented:
- Must: must-have features that have to be implemented
- Should: features to implement after the must-haves
- Could: features that could be implemented if they don’t compromise the must-haves or should-have features
- Won’t: features that won’t be implemented at the moment.
The backlog connects the development team with the product owner.
They can adapt the priorities of the requirements at any time
if the stakeholders want it.
The advantages summarized
So, the product owner together with the developers adapt the project backlog and with it the priorities in order to fulfil the wishes and circumstances of the stakeholders. They can also completely reject the requirements. This product backlog refining or grooming makes it possible to react quickly and flexibly to changes. At the same time, the developers already have a clear overview of the tasks that they have to process. This way, there is only one source of information and misunderstandings are reduced. Stakeholders also always know which requirements their team is working on at the moment – and every participant in the project can be sure that the most important tasks are currently being worked on.