Product Backlog (PB) is a list of product features that must be turned into software functionalities through a series of interations called Sprints. Product Backlog Items (PMI), which are sometimes referred to as Stories, are typically listed by the Product Owner (PO) in the PB based on the priorities determined by the PO. There is no problem assigning each PBI its equivalent priority as it signifies how important it is to develop such feature the soonest time possible. However, it rarely happens in our software projects that PMIs are developed based on the priorities assigned by the PO because each software feature may be dependent on other features that have lowest priorites. As such, features that have lowest priorities must be developed first prior to working on PMIs with highest priorities. Take the following example which is a simplified scenrio of one of my previous projects.
During the first Sprint planning meeting, our PO presented a prioritized list of PMIs to the Development Team (DT) as follows:
- Store Front
- Shopping Cart
- Inventory
- Catalog
- Invoicing
- Coupon
- Gift Certificate
- Payment Gateway
- Membership
- Mailing List
- Distribution
- Warehousing
The list was based on many variables and assumptions but our DT was not comfortable building the system based on the prioritized list because some features would be dependent on the others. Also, the PO emphasized that making the product become useful the soonest time possible is a primary consideration. For instance, the PO wanted a functionality in which the Store Front is readily available for users to register their accounts event the Catalog is not present yet. During the registration process, the user may opt-in to receive a notification when the Catalog becomes available. Also, the PO wanted that the permissions of a user are checked whenever he or she tries to add items to the inventory. With these functionalities, it is clear that the Membership must be developed first to provide user registration and roles assignment. With the permission of the PO, our DT reordered the list based on their values, dependencies and priorities as shown below:
- Membership
- Mailing List
- Store Front
- Inventory
- Catalog
- Shopping Cart
- Payment Gateway
- Invoicing
- Coupon
- Gift Certificate
- Distribution
- Warehousing
It did not take much effort to reorder the list as the DT has experience with similar product to be developed. Once the reordering was done, the list was presented to the PO who has the sole authority over the PB. The PO approved the ordering and we then continued with the meeting with the Team committed to deliver a number of PMI based on its velocity. The Sprint planning meeting lasted for less than 8 hours and the Sprint proceeded as planned.
Does developing PMIs with lower priorities over those with higher priorities violate the fundamentals of Scrum? The answer probably would depend on reference materials you refer to when practising Scrum in your organization.
Ken Swaber and Jeff Sutherland who are referred to by many people as creators of Scrum wrote on their latest Scrum guide dated October 2011 that:
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. … The Product Backlog is often ordered by value, risk, priority, and necessity.
Clearly, the Scrum guide tells us that ordering must not rest alone to the priorities assigned to PMIs but also to other variables that make the product more valuable and useful as it is being developed during the series of Sprints.
James O. Coplien explained in his article at scrumalliance.com that:
To use the term “ordering” instead of “prioritization” also makes it clear that the Product Owner must make decisions. He or she cannot just say “These five items are all priority 1; these three items are priority 2” and so forth. The product owner must deliver a totally ordered Product Backlog.
Allan Mangune 