Introduction – Product Backlog
A well-organized and prioritized Product Backlog is essential for any agile project. It not only makes planning for the release and iteration simpler, but it also quickly transmits all the customer’s needs to the team.
In addition, the Product Backlog helps to manage the expectations of stakeholders and other teams, especially when some additional work needs to be inserted into the project. But, what exactly is a Product Backlog?
What is a Product Backlog?
A Product Backlog is a prioritized list, containing brief descriptions of all the desired functionality for the product. In agile projects it is not necessary to start a project with a long initial effort, collecting and documenting all the requirements at once.
Usually, the team and the Product Owner write and prioritize the initial items of the Product Backlog, these items being sufficient for the team to start the first iteration. The Product Backlog will grow and change as you learn more about the product and the customer.
The Product Backlog makes teams feel more self-organizing, as long as there is capacity, work can be pulled and developed, either continuously through Kanban or through iterations through Scrum.
How important is the Product Backlog?
The Product Backlog is an essential tool for any project. After all, it serves as the main reference when planning all the other stages of execution.
Product Backlog is where you define the project requirement, what it needs to contain, what the client’s needs are and how the team will meet them. It also defines the priorities of the project, which must be done first. Therefore, it serves as a guide for you and the team. It is from there that the Sprint will be defined, as well as the goals and objectives of the project.
In addition, when faced with a problem or the need to make a decision regarding the project, the Product Backlog should be the main reference. It is necessary to consult the priorities of the project in order to make decisions according to the main needs of the clients that need to be met, ensuring the best final result.
Keeping the Product Backlog healthy
Once the Product Backlog is built, it is important to keep it healthy. The Product Owner should review the backlog before each iteration planning meeting to ensure that the prioritization is correct and that feedback from the last iteration has been incorporated. The regular evaluation of the Product Backlog is called “Backlog Grooming” in agile circles.
The purpose of Backlog Grooming meetings is to improve the Product Backlog. In fact, the word Grooming in English means to take care of appearance, keep it clean and tidy. A Backlog Grooming meeting must be held near the end of the iteration, thus ensuring that the Product Backlog is always ready for the next one.
During a Backlog Grooming meeting, the team and the Product Owner discuss the main items of the Backlog. The team is given the chance to ask questions that normally arise during iteration planning, such as:
What should happen if the user enters the wrong data here? Will every user be allowed to access that part of the system? What happens if …?
When raising these questions at the Backlog Grooming meeting, the Product Owner has the chance to look for all the answers that are not on the tip of the tongue, until planning the next iteration (sprint).
If these questions were asked for the first time in the planning of the iteration, perhaps many could not be answered, being necessary to put one or more items from the “high priority” Product Backlog to the side, and not work on them during the iteration that begins .
Characteristics of a good Product Backlog – DEEP
What is DEEP?
DEEP is an acronym for: Detailed, Estimated, Emerging and Prioritized. Originally: Detailed, Estimated, Emergent and Prioritized.
These are some concepts that are used to define if the Product Backlog “is good”.
Of course, for a Product to be successful, it is not enough to just have a DEEP Product Backlog. A successful product is – theoretically – one that has a Product Backlog with DEEP items, which are in line with the vision / objective of the product.
The stories at the top of the Product Backlog need to be detailed enough for it to be understood and developed by the responsible team. Understand that “enough detail” varies from activity to activity. For some, only a few words are necessary, for others, it may contain wireframes, relational models, or a series of other information.
The stories in the middle of the Product Backlog must already have some level of detail, but still very superficial.
The stories that are from the middle down can be understood as epic. They should contain only a few words for them to be widely understood.
This idea is also called “Product Backlog Iceberg”. Because only the items that are above the “water” surface are “visible” and that is why they are very detailed and the level of detail decreases the lower the item’s priority.
All stories in the Product Backlog must be estimated by the development team. The ideal is to use some measure estimation unit such as “Effort” or “Story Points” – run away from hours.
Of course, the smaller the detail of the story, the more inaccurate your estimate will be. To get around this, as the stories “go up on the Iceberg” – that is, being detailed – they are also re-estimated by the team.
But then, what is the key point in estimating something that is not ready?
These estimates are used by the Product Owner to design a Release Plan or Roadmap, of course, he cannot commit to an exact date because of inaccurate estimates, but he certainly can predict whether the delivery of a particular story will be made in the next month, quarter, semester or year.
New stories are emerging all the time in the Product Backlog, this is natural as the product is better understood by everyone involved. These “new needs”, in traditional project management models, would be treated as changes in scope. In the agile model, there is no such concept because the Product Backlog is constantly re-prioritized, and therefore, if a story has emerged, and it is essential to the product, it can be put to development in the next sprint.
An important feature is the constant (re-) prioritization of the Product Backlog. Usually, stories should be prioritized taking into account their value to the business.
One last point, as the Product Backlog is a single prioritized list, there are no two stories with the same priority. A story is less of a priority than the one above it and more of a priority than the one below it.
Attention points with the product backlog
When implementing the Product Backlog, be careful and pay attention to these points:
- Avoid very large and complex items, giving preference to separating them into smaller topics;
- Only involve those who are needed in the Backlog, avoiding conflicts;
- Define the quality criteria and acceptance criteria, so that the Product Backlog is applied in the best possible way;
- Correct estimates that prove to be inadequate over time;
- Formalize the entire process to ensure knowledge management in the company.