Without a shadow of a doubt, a product backlog is one of the most important things when we talk about an agile way of software development. Backlog is a place where all your product requirements should be stored. These requirements are called PBI – Product Backlog Items.
Backlog is also a tool that can help your team with proper planning. Its aim is to:
- facilitate your team with delivering the greatest value possible
- ease workflow and track work progress
In this post, we would like to devote our attention to product backlog. What are the good product backlog features and how to use them.
Ok, sit comfortably in your chair and let’s walk through the world of agile product backlog! Enjoy the read!
1. A good product backlog is ORDERED
Simply speaking – the items are arranged in order of execution.
Priority is significant here, which means that two different items cannot be equal with regards to importance – one needs to be precede the other (closer to the top of the backlog).
Backlog is also the only place where requirements are stored. Therefore, before we place any new requirement we must fully consider its value and importance.
A product owner is a person responsible for arranging the backlog and putting the items in the right order. Product owner should aim at stacking the requirements on the backlog, so that with every iteration a new version of software can be delivered.
We should keep one thing in mind when we talk about product backlog. It can be organized in a variety of ways – everything depends on the context!
2. A good product backlog is RELEVANT
Contains items relevant to the current requirements and needs.
A brilliant and very useful benefit of the agile way of software development is that it allows us to constantly check whether our product corresponds with the expectations. If not, we can just adjust it or change it (with regards to the Inspect&Adapt rule). It’s as simple as that :)
3. A good product backlog is TRANSPARENT
It’s visible and legible to all those parties involved.
Backlog can be adjusted when needed. However, it can only be done easily when it’s transparent and all interested people can get acquainted with it and understand it well.
It’s way easier to talk about some items and their importance with product owner (and maybe convince him to move our awesome feature to the top) when it’s clear and legible.
It’s absolutely great when a backlog item has a format of a user story:
As a [role] I want [a goal], so that [benefit]
This format not only facilitates the creation of requirements that are intuitively understandable for all concerned but also it tends to think in terms of the users needs.
4. A good product backlog is REFINED
The level of detail is adapted to the requirements of its position in the backlog.
A refined product backlog is one where requirements are adequately sized up to their position. Moreover, all requirements on top should be clear and well understood and ready to planned on.
This characteristic can save us a lot of time and unnecessary effort. Because of that, we can avoid a situation where we see huge, vague requirement on top of our backlog, where the team spent lots of time analyzing it before starting a new iteration.
Good product backlog should have a pyramid structure – a number of very small (decomposed) requirements on top, increasing requirements somewhere in the middle and keeping large, general ideas on the very bottom.
It’s rather obvious that those requirements that are on the top should be small enough to be performed in next sprint.
One more thing…
There are many ways to manage requirements and backlogs, it depends on various factors like product type or product lifecycle. A lesson that we need to learn is that we should stay flexible and open when thinking about choosing the right way, relevant to our needs.