Working with Product Backlog #1
Product Backlog is how Product Owners communicate with the Development Team frequently. A good product backlog determines how well the Dev Team delivers the desired product. As a book for development, are we familiar with the product backlog?
The Product Backlog is an ordered list of everything that is known to be needed in the product
In the 2020 Scrum Guide, The Product Backlog defines with an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
The Product Backlog is a breakdown of the work that must be done to reach a product that is ready to deliver. The Product Backlog consists of a list of Product Requirements called Product Backlog Items (PBI).
The Product Backlog Items often include test descriptions that will prove its completeness when the development is “Done”.
Product Backlog items have the attributes of a description, order, estimate, and value.
- What’s in the Product Backlog? Product Backlog contains definitions for features, functionality, requirements, defects, or enhancements of the product.
- Who is involved in the Product Backlog? The Product Owner acts as a stakeholder who is responsible for the voice of the customers who will design, manage, and maintain the product backlog to maximize the value that will be delivered by the team.
- What is the form of the Product Backlog? The Product Backlog will usually be in the form of user stories, use cases, or free text. However, many teams define that the Product Backlog will be easier to understand by using the user stories format, namely:
“As a [user], I want to [doing clever thing]. So that [customers problem can be help].”
Product Backlog Rules
- There are no two Product Backlog Items that have the same priority in a product backlog
- Maybe we can found flaws in the Product Backlog. It is okay because it can be fixed in the next Sprint
- Product Backlog can be refined again to ensure readiness and understanding during Sprint Planning
- Stakeholders can suggest new Product Backlog Items, but the decision to add Product Backlog Items to Product Backlogs rests with the Product Owner
- Product Backlog must be known by every stakeholder involved but can be represented in a different format for each stakeholder
As long as the product exists, the backlog also exists.
Product Backlog Characteristics
Roman Pichler (Pichler 2010) and Mike Cohn coined the acronym DEEP to summarize several important characteristics of good product backlogs:
- Detailed Appropriately, the Product Backlog Item must be detailed in the correct order. The most detailed Product Backlog Item and getting a short estimate will be a priority to work on and for the less detailed Product Backlog Item it is better to break it down into more detailed Product Backlog Item
- Emergent, Product Backlog Item is dynamic and can change according to changing requirements. Changes can occur during the development process. If the Product Backlog Item changes, the priorities and estimates also change
- Estimated, Each Product Backlog Item must have an estimate for the size of the work. The estimation used can use Story Points, Planning Poker, or Use Case Points or use T-Shirt Size (S-M-L-XL) if the product backlog is too large and not too priority
- Prioritized, all existing Product Backlog Items are a priority for the development process. However, it must be re-arranged to what level the priority of the Product Backlog Item is and it must be determined which Product Backlog Item has the highest priority.
Every Product Backlog Item is a priority, but we have to manage what Product Backlog Item comes the number one, two, and more
- Rubin, KS. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley
- Scrum Guide 2020
- How to Manage Product Backlog with DEEP Principles?
- What is DEEP in Product Backlog?