The Product Backlog must be ordered so that the Product Backlog Items represent a sequence of valuable pieces of product to be built. There is always a first item (not two or three first items) then a next item, etc. until you get to the end of the list. The list is “ordered” so that there is a strict sequence with exactly one Product Backlog Item at each position in the list. The sequence is determined by the Product Owner and is used during Sprint Planning to determine what the team will do.
This ordering helps to create a clarity around choosing what should be done next. It also encourages the Product Owner and the Scrum Team to think about how to break dependencies. If two or more Product Backlog Items have the same position in the Product Backlog, it means that the Product Owner has not prepared for the Sprint Planning meeting and the team may be less effective in that meeting. Having two or more Product Backlog Items in the same position in the Product Backlog is, in fact, a slippery slope that can lead to very poor prioritization, and even sub-optimal results from the team. Minor or occasional deviations from this rule will have a low impact. Categorizing Product Backlog Items into a small set of priority levels (e.g. MoSCoW prioritization) will reduce the effectiveness of the Sprint Planning Meeting dramatically and so should be avoided.
The reasons for this rule are simple: (1) The Product Owner’s decisions must be visible in the content and ordering of the Product Backlog; and (2) the Product Owner orders the Product Backlog to maximize the value of the product and the output of the team. If the ordering of the backlog is ambiguous then the Development Team may have to resort to complex negotiation with stakeholders, committees, or other teams.
Product Owners must order the Product Backlog. And they can do so any way they see fit. It is important that planning activities and analysis of the work do not get in the way of the work. Scrum Teams want to minimize wasteful and conjectural analysis.
Product Owners and Scrum Masters may require strong facilitation skills in order to work with stakeholders to provide the Development Team with an effectively ordered Product Backlog. Ideally, stakeholders have a unified vision of the Product. If they do not, stakeholders may compete, lobby, coerce in order to achieve their individual goals. It is essential that the Product Owner work diligently to clarify and communicate the Product vision so as to create alignment among stakeholders – thus making the ordering of the Product Backlog easier.
Putting items in a specific sequence can be intellectually and emotionally challenging. Therefore, simple and quick techniques often work best for creating an ordered list of Product Backlog Items. The following four techniques are easy to try depending on the circumstances of the Product Owner and the Scrum Team:
- 1-2-3-later. In this technique, the Product Owner looks through all the Product Backlog Items three times. The first time, the Product Owner tries to find the most important Product Backlog Item to be done next by the team. This item is set aside. The second time through the items, the Product Owner looks for the next most important item. The third time through repeats the process. All the rest of the items are left in whatever is their current order (including if that is random!) The three items chosen are re-examined to ensure they are in 1st, 2nd and 3rd ordering correctly, and adjusted if necessary. This technique is “good enough” to get started, and can be used just-in-time before the start of each Sprint if desired. This technique works well when there are fewer than 25 Product Backlog Items.
- Simple two-factor ordering. First the Product Owner gives each Product Backlog Item a business “value” from 0 to 5 with higher numbers meaning that they are more valuable to the business. Then, the Product Owner takes the items to the Scrum Team to get the team to categorize the items into two groups: 1) small enough to easily be completed in a single Sprint if the whole team swarms the item, and 2) everything else too big to fit into a single Sprint or uncertain about fitting into a Sprint. The Product Owner looks at the items that are small enough and puts them in order mostly based on the business value score. Likewise, the other items are also ordered by their business value score. This technique still requires some thought if there are multiple items in a category that have the same business value score, but the Product Owner should only focus on items in the “small enough” category for this disambiguation work. The other items can be left in a near-random order. This technique works well when there are between 20 and 50 Product Backlog Items.
- Relative return on investment. In this technique, the Product Owner involves customers, users and other business stakeholders to quickly estimate business value of Product Backlog Items using the “Bucket System of Estimation”. These collaborative value estimates are recorded with the Product Backlog Items. Then, the Product Owner asks the Scrum Team to use the same bucket system technique to provide effort estimates for the items. Again, these collaborative effort estimates are recorded with the associated items. Then, using the business value and effort estimates, each Product Backlog Item is given a calculated “Relative ROI” by dividing business value by effort. The items are then sorted with the highest Relative ROI at the top of the backlog. Again, there may be a small amount of disambiguation work to be done. This technique works well when there are between 40 and 200 Product Backlog Items.
- FIFO with Expedited Items. In this technique, the Product Backlog Items are done in the order in which they are requested (first-in-first-out – “FIFO”) with the exception that the Product Owner can move a fixed number of items (usually just one or two) up to the top of the list at the start of each Sprint. As well, the Product Owner can also permanently remove items from the Product Backlog. This technique works for any number of Product Backlog Items, but only if they are always small enough to be easily completed in a single Sprint.
The Product Backlog is an ordered list of everything that might be needed in the product — The Scrum Guide
Register now to practice these ordering techniques and others in our:
Product Owner Boot Camp with CSPO (with bonus Kanban for Product Owners certificate)