Prioritized backlog versus Release-based Planning

In a previous post, I wrote about the differences between requirements and backlog items and how backlogs should be DEEP, i.e. Detailled appropriately, Emergent, Estimated and Prioritized. But is there such a thing as a prioritized backlog?

The general idea is deceptively simple, if you simply start with the most important thing and keep going for as long as your budget lasts the total importance of your achievement should be maximized. In some more advanced versions you also consider the ROI of each backlog item (ROI=value/cost) and do the top ROI items first.

Reasons why it is hard to have a prioritized backlog

But in practice there are many reasons why it is not possible to create a DEEP backlog:

• Absentee stakeholders
• Multiple stakeholders
• Uncertain values
• Time and order dependent effort
• Time dependent value

Absentee stakeholders

To quote one customer when we presented the agile concept: “But how on earth shall we have time to interact so much with you on top of our regular work”. Many customers think it is enough to give more or less vague goals and then let the supplier or other non-decision makers fill in the gaps and provide the details. With little to know participation from key stakeholders, prioritization becomes very hard.

Multiple stakeholders

This is also a very common situation. Multiple stakeholders with different interests have totally different priorities. Whatever you do in terms of setting priorities, someone or perhaps even everyone will be unhappy.

Uncertain values

Often the value of a certain feature is uncertain. How much extra would an external customer actually pay for this feature? Market driven requirements engineering tries to answer this question. More about why this does not really work can be found in “Why Prioritizing your Agile Backlog for ROI doesn’t Work”

Time and order dependent effort

Whatever we do, we have to do some upfront work the first time we do it. Next thing will be easier. Unless of course doing one thing first takes us down a path which makes it harder to do the other thing second.

Time dependent value

It is rather obvious that a christmas calendar function has rather low value in January and February.

Source: Alan Daley on Flickr | CC BY NC SA 2.0

A house chores backlog. Definitely not a a prioritized backlog. By Alan Daley on Flickr. Used under CC BY NC SA 2.0

Minimally Meaningful Releases

So if prioritizing features is so hard, what are the alternatives? First of all, prioritizing features does work for some projects so if you have not tried it yet don’t give up at once. One of my favourite alternatives is release based backlog planning. Often, it is much easier to divide backlog items into the next release, the release after that, a future release and out-of-scope. This kind of four (or five, or six …) levels of priorities makes it relatively easy for stakeholders to agree on prioritities. It can then be left to the team to prioritize the features internally in terms of which feature belongs in which iteration.

So how big is a release? I have found that using a “minimally meaningful release” (MMR) (cf. lagomizing) concept is highly useful. The MMR is simply the smallest feature set that can possibly be released with some amount of pride on the developer side and value and satisfaction on the user side. Read “Why there should not be a Release Backlog” by Mike Cohn to get a contrarian view.

Note that this approach kind of requires that the duration of times between releases is allowed to be variable.

Update

This post about prioritized backlogs (or not) was originally posted on Nov 15, 2010. It was updated slightly on Dec 28, 2013. The changes were editorial in nature.