Product Backlog Ordering, Sequence for Success

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.

Chris,

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?

Thoughts?

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).

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.

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).

Chris

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

Product Backlog Prioritization

Rules
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

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

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

Chris,

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!

srinj.dyndns.org/srinj/wiki/BacklogPrioritization

Tarun,

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.

David,
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.