Putting Your Product Backlog in Order

Earlier versions of Scrum described prioritizing the Product Backlog based on development priority, but the current Scrum Guide just says that it is ordered in order to “best achieve goals and missions” (Scrum Guide, July 2013). Ordering the backlog is the responsibility of the Product Owner, who is also responsible for optimizing the value of the work that the Development Team performs.

Getting the business to admit that not every feature is equally important is often challenging, so having some good ordering techniques is helpful! Small user stories with dependencies between them also make this process challenging, so you may want to group dependent stories before ordering them.

Techniques for ordering the backlog include classification techniques like High/Medium/Low or numbering 1..n, as well as more complex techniques like value mapping, user story mapping, and the Kano model.

Among the classification techniques, I personally like using the MoSCoW rules, which make the criteria for ordering clearer than using High/Medium/Low:

• Must Haves are features that are fundamental to the product, and need to be included in a delivery.
• Should Haves are also very important but if they are not included in a delivery, the product will still function. (Anything that has a workaround is usually a Should Have.)
• Could Haves are nice to have features that can be left out of a delivery if time runs short.
• Won’t Haves are desired features, but will not be included in this delivery based on the goals of the delivery or release.

Using the MoSCoW criteria to order your backlog items also gives you flexibility in Sprint planning. You will probably have quite a few Must Haves, but you can select from them in terms of which features make sense to do first, and which ones make sense to do together. When you order the backlog using numbers from 1..n, most teams feel compelled to start at the top of the backlog and work down, which doesn’t allow for much flexibility in planning.

Value mapping considers two dimensions, such as revenue vs. effort or cost, time to market vs. attractiveness, etc. A value map has four quadrants, with the appropriate criteria on each axis. (Note that the ordering shown in the example may change based on the criteria you use for each axis.)

Value map example, using revenue vs. effort:

Once you have mapped the features, you can apply the MoSCoW rules to them to refine the ordering.

Value mapping can also be based on frequency of use.

In the follow example, the high value features would be clustered in the upper right columns and rows.

Adapted from Des Traynor, Intercom.io

If your business stakeholders push back on assigning an order to features on the backlog (“everything is critical”), remind them that the purpose of ordering is to make sure that the Development Team is always working on the features that will deliver the most value. If everything on the backlog has equivalent value, then it’s up to the Development Team to decide what to work on first, which might not be what the business stakeholders want!