How to Prioritize Your Backlog and Go Live ASAP
By Bruno Collet
We will look at a 7-step technique to prioritize a product backlog in order to release a working system in the shortest possible timeframe. This article is presented with a methodology-neutral point of view; it can be used with any Agile-style framework.
Step 1: Describe the Target Release
The goal of prioritizing the product backlog is to to release the desired product as soon as possible. The key here is to define the “desired product”. Before even starting the prioritization, every stakeholder has to agree on the the objective of the release. For example, it can be a prototype, a public beta, or a update to an existing commercial version. The characteristics of the release must be expressed in a few lines in the form of benefits or high-level features that deliver value to users and/or clients.
An example for the first private beta of a job searching website would be:
It allows users to search and apply for jobs in the most basic way. It allows recruiters to post a job description and receive applications in the most basic way.
The description makes it clear what features must be included in the release. With “in the most basic way”, it also explicitly states that all kinds of features or perks not necessary for these features are to be excluded from the release. Any stakeholder reading this description should be able to prioritize the backlog items.
Step 2: Define the Minimal System
If we look at any backlog, we’ll notice that it tends to include everything everyone thought might be nice to have. In other words, a lot more than what we want and need for the target release. What we need to do here is to define the minimal system that satisfies the release description. You might be familiar with the categorization of features into “must have”, “should have”, or “nice to have” (have a look at the MoSCoW prioritization technique). Well, here we want exclusively the “must have” items.
For the remaining steps, we’ll only work with the items of the minimal system. We leave the rest for further releases.
Step 3: Even-out the Size of Backlog Items
This step is optional but often comes handy because most of the time the backlog contains items of wildly different sizes (in terms of scope and effort), such as “manage user registration” and “add a date column in the list of jobs”. Because it would be hard to compare such items with the simple scale we’ll use later, it is useful to split and/or merge items in order to have comparable sizes. To be more specific, it’s ok to have items that are (intuitively) 5 times “bigger” than others, but not a hundred times. Typically, many tiny items will refer to related features such as sorting, filtering, adding fields and the like. They can easily be merged based on the functional proximity. An example of resulting item would be “manipulate the list of jobs of a search result”. Merged items would become child items or tasks in the new item.
Step 4: Estimate the Value of Items
For each item of the backlog of the minimal system, we assign a value on a scale of low / medium / high. I suggest keeping the scale simple because it would usually be futile to try to categorize items more precisely. Note that the value refers to the value as defined by the user/client, and does not take into account measures such as return on investment or cost.
Step 5: Merge Results from Multiple Stakeholders
This step is optional but in my experience several people have a say in the definition and prioritization of the minimal system. I suggest that each of these stakeholders performs Steps 2-to-4 individually and then get together to compare and merge their results. Indeed I have noticed that this is more efficient than gathering all prioritizing stakeholders to do it from scratch. If you are lucky enough to have only one person responsible for prioritizing the backlog in your project, you can skip this step.
Step 6: Estimate the Cost of Items
In the same way we estimated the value of items in Step 4, now we estimate the cost of items on a similar scale of low / medium / high. Depending on the project, the cost may refer to the development effort or include other components. This categorization should be performed by the people who will actually do the work of implementing the items.
Step 7: Prioritize According to Business Value
Finally, we prioritize the backlog according to the business value, which is defined as the combination of value (see step 4) and cost (see step 6). Indeed we want to prioritize the delivery of items based on the “best bang for the bucks”.
I suggest the following scale:
If you want to quantify the business value, you may for example assign values of 1 to low, 3 to medium, and 5 to high for both value and cost, and then quantify the business value as value divided by cost, as indicated in the “business value” column. The 1/3/5 is a good scale because it usually reflects well the difference in size (both in value and in cost) between items. You can use more detailed scales but you will probably notice that it generates a lot more work for little additional benefit.
Depending on your planning needs, you can for example assign real values to cost, such as a numbers of days of development, and see where it gets you across iterations with your current velocity. It’s a good reality check but keep in mind that it’s a guesstimate and it’s bound to change, so don’t over-analyze. Just enough planning is enough planning.
Bruno Collet combines business acumen with technology know-how. His successful track record comprises Daimler-Chrysler, Siemens, and Loto-Quebec, with roles such as management consultant, project manager, SAP consultant, and software architect. Bruno Collet’s skills are firmly grounded in academic excellence by achieving an MBA at John Molson School of Business and a Master of Computer Science. He maintains a professional website: brunocollet.com.