Product Backlog Ordering, Sequence for Success

| by David Bulkin Follow 0 Followers on Dec 29, 2011. Estimated reading time: 2 minutes |

Product BacklogHistorically, some product owners have prioritized backlogs by making pairwise comparison of projected economic return between two items in isolation. Successful Agile teams often take a holistic approach, accounting for risk, dependencies, and the complex interplay among and across backlog items.

An article on the Scrum Alliance site by James O. Coplien, published on August 3rd, 2011, but still drawing comments, addresses changes in the updated Scrum Guide as it relates to product backlog prioritization, or as James explains, ordering.

To prioritize a list means to order its items by their importance relative to each other. Priorities drive pair-wise comparisons (by English language definition) of items on the list. Think of using bubble sort to prioritize the Product Backlog: compare the top two items and interchange them if they’re in the wrong order, and then move on to the next pair, and keep cycling through the list until everything is in its place. Prioritization and sorting go hand in hand. All the comparisons are local. This process is analogous to local optimization.

More broadly, the Scrum Team and the Product Owner in particular need to consider the entire backlog when ordering PBIs, to optimize value or ROI. Most people commonly think of ROI as the priority; however, you need to think of ROI as a long-term result of the total backlog ordering rather than just the sum of the ROI of individual items. This is true in part because the ROI of an individual item depends on its position in the backlog.

Arlen Bankston, an Agile Trainer and Consultant, further explains the need to look beyond direct ROI contribution of an item.

The value in individual stories -- especially in early stages of new product development efforts -- is often found more in the feedback they provide about features' fit and fitness to market and customer needs, than in direct contribution to ROI. This makes simple pairwise comparison of individual stories an overly narrow approach, as overall patterns of product and customer discovery must be considered in addition to income generation.

Others in the agile community have used variations on the ordering theme for quite some time. Several years ago, during conversation, Roland Cuellar explained that a better term is sequence to market, where sequence combines business, technical and other factors such as risk and dependencies. Using the word sequence helps because it allows product management to move beyond the concept that everything is high priority by stating, yes, that may be true, but let’s determine which high priority item comes next.

So, whether it is called ordering, prioritizing or sequencing, effective product owners  look holistically at their backlogs to ensure that items are delivered to maximize both immediate and long term value.

What have been your experiences along these lines?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I cannot believe people are still ordering their backlog. by Chris Matts

Ordering your backlog is the IT equivalent of ordering your CD collection. some argue its best to order by name and others by genre or release date. Its something to do when you have nothing valuable to do to justify your existence on a project.

So the message should be simple. Ordering ( or grooming ) yuour backlog is waste. SO STOP DOING IT!.

Instead each time you have capacity, simply pick the next thing to work on. In order to do this, include all stakeholders in the decision.... business and IT. If you do it frequently, it take very little time.

So the first item on the list... Sack whoever is currently ordering the backlog because they do not have any valuable work to do.

Re: I cannot believe people are still ordering their backlog. by David Bulkin


I love comments like this; it stirs the pot to cause conversation!

If I understand your response correctly, you are still recommending prioritization but as a just in time, small batch (one piece actually) process. In some environments that will work perfectly.

But, are there environments where this won’t be the best option? What if the other stakeholders are not readily accessible? What if your team has to make external commitments in advance?

Perhaps we can state this. If your team wants a predefined delivery plan (e.g. acknowledging that not all require it) then you should determine the sequence to market quickly, continuously, collaboratively, and the team plus appropriate stakeholders should review just in time when there is availability for working on the next item.

This is similar to the debate about estimation being wasteful (e.g. don’t estimate size). My experience has been that estimation can be incredibly wasteful when it is done slowly, and that it can be incredibly valuable when done quickly. Can the same apply to determining sequence to market?


Re: I cannot believe people are still ordering their backlog. by Roopesh Shenoy

Although the extent depends on whether you are on an internal IT project or a product development project, some prioritization always needs to be done. I have worked in both settings so this is what my experience has been.

In IT projects, stakeholders typically know what needs to be done, and can keep raising Change/Feature requests, but since different stakeholders have different priorities, the project owner needs to decide what things get done first. Again, that depends completely upon benefit/cost with things like Risk also accounted for.

In Product development projects, the company stakeholders normally do not know what needs to be done - people who know are either the customers (because they actually use the product) or the innovators/product designers (whose job it is to decide what should go into the product to make it marketable). You never have sufficient resources to do it all, so it needs to be prioritized based on value (will this create more sales volume? will people pay more for it? is this a feature bug? etc.)

Taking the next thing that comes along ends up being very wasteful - you take up things based on who shouts more, rather than making a concious decision based on what is good for business. It's a different thing whether this prioritization is a full-time job (depending on size of the project, the person might work on multiple projects at the same time or may double up in other roles) but there needs to be a clear owner who is both responsible and accountable for the success of a project (not just the technical success but making sure that the project actually meets business goals).

Re: I cannot believe people are still ordering their backlog. by Shawn Crosby

I supposed it depends if you are scope boxing or time boxing your release. If you've spent hours or days in a boardroom figuring out what your next release is going to look like and then lied about when it will be ready, then don't bother prioritizing. But if you know that you will release in 90 days and you want to get as much value out the door as you can, then tell your product owner to keep your backlog ship shape at all times so that the team can just pick the next work item off the top of the list and then release on time and frequently.

Sorry, not prioritizing your backlog is bad advice.

Re: I cannot believe people are still ordering their backlog. by Chris Matts

Thank you guys. I'm loving the discussion.

You each seem to be saying a variant on the same thing... If your governance structure and investment decision process is broken, then you need to prioritise the backlog.

My (bad) advice is, If your governance structure and investment decision process is broken, then FIX IT so that you do not have to distort your development process to be sub-optimal for the delivery of value. Get all your stakeholders together in a frequent (weekly ?) and short (5 - 10 minutes) to decide the next investment. I normally piggy back off an existing meeting. The single wringable neck (product owner) allways seemed like a over simplistic solution to a problem that is not that difficult to fix properly.

This structure means that whoever shouts the most does not get what they want... unless they convince everyone else. Also, it is the other stakeholders that tell them they have to wait. It prevents the situation where IT are in the middle telling people what they can have. They need to do it frequently so that they can get good at it. Also it means they do not have to wait that long for the next investment decision and might be convince to drop a requirement (for now).


P.S. Thank you David for your kind comment. Just stirring the pot. :-)

Product Backlog Prioritization Algorithm by Tarun Sukhani

Product Backlog Prioritization

1. Story point totals must not exceed commitment
2. Items must be independent except when there are no other items remaining to be worked on
3. Items on the critical path take precedence
4. Items not on the critical path must be chosen such that those that have the earliest critical path dependencies take precedence, with length/size and business value (if present) following suit - i.e., earliest critical path dependency > length/size > business value

1. Dependency-Ordered Product Backlog
2. Business points attained per release or backlog item cutoffs (optional)

1. Priority-Ordered Product Backlog
2. Release plan (if Input 2. is provided)

Re: I cannot believe people are still ordering their backlog. by David Bulkin


Let’s assume that we all agree that frequent, short prioritization meetings, with an extended group of stakeholders, is a good thing. Let’s further assume that by having these meetings frequently we get good at them and thus get agreement on what to work on next.

What happens if we need approval from external groups like legal, compliance, security, privacy, etc., and getting this approval is not something that can happen at a short meeting (e.g. if we get them into the meeting it by definition becomes a much longer discussion)?

Or, let’s assume that we have many interdependencies with other teams who we must integrate with, and that when we pick the next item, we don’t necessarily know what the downstream and upstream impacts are?

In short, are there situations in which you would advocate prioritizing at least a short list of upcoming items so that some amount of work can be done to mature the upcoming items to mature them to be ready to be worked on?

And yes, thanks for stirring the pot!

Greedy Approximation Heuristic for automated backlog prioritization by Tarun Sukhani

Re: Greedy Approximation Heuristic for automated backlog prioritization by David Bulkin


Interesting perspective that goes beyond prioritization to assignment. I look forward to a further definition of second approach.

In respect to the first approach, let me ask about step 3, “Items on the critical path take precedence”. This implies (at least to me) that you have a detailed understanding of what you want to deliver, the effort ahead, and the interdependencies. This is a 180 (e.g. mirror opposite) of what I read from Chris’s comment.

Looking at this from a slightly different angle, understanding the critical path can imply more of a traditional project perspective (e.g. fixed time, scope and schedule) versus the traditional agile perspective of an evolving product that maximizes value.

I am interested in your input as to if I am reading this correctly, and, if so, what the window of future visibility is that you believe to be appropriate.

Re: Greedy Approximation Heuristic for automated backlog prioritization by Tarun Sukhani

My approach to Agile project management is a fusion of traditional and agile practices. I don't accept that the latter is necessarily a radical departure from the former. For one thing, precedence rules still apply in Agile projects. That's why, in the literature, product backlogs are no longer "prioritized", but "ordered" (revised Scrum guide). Indeed, it should never have been worded as "prioritized" in the first place. I take a more systematic approach to project requirements gathering that ALWAYS organizes requirements into a hierarchy of Theme -> Feature -> Story (different levels of abstraction done via a mindmap) and then uses the features as backlog items. The user story map then lists the Themes as columns and features as lanes for each sprint. In this way, the features that can be done within a particular sprint become the spring goal (I in fact label the sprint goal according to the features for that sprint). This is a form of "Convention over Configuration". By accepting this rubric, benefits such as being able to guide assignment algorithmically become possible, including the identification of sprint goals.

Some may complain that I'm ignoring the "emergent" aspect of Agile development, but in fact I'm not. Rather than focusing on the story level, I'm focusing on the feature level and asking how this feature fits in into the overall software effort. For example, if it's a feature about writing a report of some kind, then we should have a theme about Report Management where it could fit in (SOA approach). Other similar features would probably already be included in that theme. Once we have that information, we can break it down into its composite user stories. However, since the dependencies we're concerned with are at the feature level, we would have a better idea of what order it could be done in. Again, the beauty of this approach is that it's at a level of abstraction that the business can easily understand, and by definition, there would be less (or equal) number of features than stories. In my projects, I found that the ratio is around 5:1 for stories:features and features:themes. A typical project, for example, may have 5 themes, 5 features/theme, and 5 stories/feature for a total of 125 stories. I also don't favor larger projects than this due to my belief that stories are basically a 1-1 mapping to a single series of interactions. In effect, Dunbar's_number applies. Anything larger than 150 stories probably means that the project should be split up. In effect, I feel as if those stories are equivalent to social interactions, and I want to be able to intimately know all of them.

By focusing on the feature level and decomposing, emerging information can be incorporated easier. What you want to deliver, for instance, becomes easier to map out. What effort lies ahead is simply the summation of the story points stories for those features. And the interdependencies are easier to see and grasp because we're looking at a higher level of abstraction. As new information gets added, the input file just gets updated, and the algorithm automatically reads it in and provides updated output. I've set it up so that the program just detects changes in the folder and automatically runs. The wiki then shows the updated dependency diagram and analysis.

So, my answer to the "fog of project completion" is to look at a higher level of abstraction and guide my development through a balanced approach to maximizing value. To me, the goal is to maximize business value while minimizing project risk.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you