Product Backlog is one of the three Scrum Artifacts. For software development teams, it is a very important artifact. So, what exactly is a Product Backlog and what makes a good Backlog? Let’s find out now
What is a Product Backlog?
In simple terms, a Product Backlog (also known as a product backlog) is a list of features that a Development Team will implement for a product. These features are prioritized and managed by the Product Owner (PO).
A product backlog will contain Product Backlog Items (PBIs). PBIs are tasks that need to be performed to develop the product, such as: Features, Bug fixes, Knowledge acquisition, Technical work, etc.
A few notes:
- Each product has only one Product Backlog.
- A Product Backlog is managed by only one PO.
- The content in the product backlog is constantly updated according to changes from customers or market needs.
- Sometimes, a large product will be divided into smaller Product Backlogs with multiple working groups. For example, the Adobe Creative Cloud ecosystem includes smaller products such as Photoshop, Illustrator, and After Effects… Corresponding to each product, there will be a separate Product Backlog and a designated team to develop it.
The role of the Product Backlog
The Product Backlog is seen as a clear plan for the Development Team. By dividing the items, the current and future direction of the product will be clearly expressed. As a result, the team will find it easier to choose items to put into production in an orderly manner.
In addition, the Product Backlog also has the following functions:
- Inspire the Scrum Team to understand the meaning of work.
- Provide a long-term vision for the team to proactively and optimize the product.
- Detail the items to be done, helping to make the planning (Sprint Planning) session effective.
- Accurately estimate work.
DEEP – The quality standard of a Product Backlog
In the book “Agile Product Management with Scrum: Creating Products That Customers Love”, the author Roman Pichler introduced the DEEP rule for creating a Product Backlog. According to this, a good product backlog should have 4 basic characteristics: Detailed appropriately, Estimated, Emergent, and Prioritized.
Detailed Appropriately – Detailed in a logical manner
The items in the Product Backlog are sorted in priority order. Important features that need to be done first will be at the top of the Backlog. On the other hand, features/tasks with low priority or dependent on other items are sorted at the bottom.
Therefore, the items at the top of the Product Backlog will be presented in more detail and clearer than the items at the bottom.
Estimated
All items in the Product Backlog must be estimated. The estimation is usually provided by the Development Team or upon request from the customer. The accuracy of the estimation of the items at the top is higher than at the bottom.
Emergent
The product backlog is not a fixed list of items to be developed and will always evolve over time. The purpose is to make the product more competitive and useful.
For example, after the product demo, the customer requests a new feature. At this point, the PO must consider adding and subtracting, reordering the priority level in the Product Backlog.
Prioritized
As mentioned, the items in the Product Backlog must be sorted by priority in order to maximize the value of the product being developed. The items that need to be produced early will be at the top of the Product Backlog.
Sorting the priority of PBI items
One of the important principles of the Product Backlog is that the PBIs must be sorted in a logical priority order. Here are some tips for sorting PBIs that you can refer to:
- By level of urgency and importance
- Resolve complex tasks first
- By consensus, the expression of the whole group
- MoSCoW method.
What specifically is MoSCoW?
MoSCoW specifically refers to a prioritization technique used in many Agile project management models. The name of this method is an acronym for: Must, Should, Could, and Would. In which:
Must: tasks that are mandatory for project success.
- Should: important activities that are less critical than Must tasks.
- Could: items that can be removed from the list if time or resources are limited.
- Would: tasks that are not in the current requirements but may be tasks in the future.
In summary, the Product Backlog is not just a prioritized list, but also a tool to manage work effectively. Besides software development, we can apply the Product Backlog to different fields of work.