Ordered backlog and ruthless prioritisation

When we create a backlog we are generating a list of work for the team.  But a backlog is not just a list of work.  Critically, a backlog is an ordered list of work.  The intent is that the items at the top of the list are those which should be done first.  Those further down should be done later.  In a well-managed backlog, the team can work through the list of work in order, knowing that this approach will deliver the most value.

Ordering or categories?

The idea of strictly ordering all work is new to many organizations.  Many organizations use an ordinal prioritisation system instead.  In an ordinal system, each work item is given one of a number of different priority levels. 

• Work could be identified as “Low Priority” up to “Critical Priority”. 
• Or we could use the popular MoSCoW system which identifies items as “Must Have” through “Should Have”, “Could Have” to “Won’t Have”.

However, ordinal systems are flawed. 

The categories seem a great idea in principle.  The implementation is usually more of a problem. Imagine someone has taken a piece of functionality (“a feature”) as far as considering and defining it.  That causes a strong desire to push for it to have a high priority.  As a result, the distribution of work priorities tends to be skewed.  Most work becomes shown as high priority, with little shown as low priority.  And over time, increasing amounts of work go into the top category.  It is not unusual to see continuous reprioritisation of those top items in an attempt to control this “category creep”, even subdividing the category to create multiple levels of “critical”.

This is due to a basic problem with ordinal systems, or really two problems.

• All items within a category are equal. 
• By the same argument all items in one category are significantly higher than any in the next category. 

This causes confusion within a category.  Which should we choose to do first if they are all equal?  No decision has been made on this, so who makes that call? There is then a large step between items in one category (which are prioritised) and those in the next category (which are not).  This can lead to significant friction about how each item is categorised because the assigned category may determine if the work is ever done.  This friction will slow decision making and limit business agility.

Managing change

An ordered backlog removes many of these issues.  There are no hard steps between categories.  And no two items are equal.  Every item has a unique position.  The tenth item on the list is above the eleventh and we would aim to do it first of the two.

It can be a challenge to introduce this concept.  There is often pushback to say that two items cannot be ordered relative to each other.  And yet at some point, when a development team chooses which to work on, an order must be set.  If a team were available right now, a decision would have to be made between the two items. Grouping into categories simply obscures and delays that decision.

As an ordered list the backlog captures the current best thinking about priorities.  We expect change.  We even, as the Agile Manifesto Principles say “welcome change”.  Which means we need the mechanisms to manage change.  Backlog ordering gives us that flexibility.  Without it, we effectively have a fixed plan showing work, all of which needs to be done.

Clarity of priorities

In Agile development we expect and welcome change.  But before you can manage change you need a “plan of record”.  There can be no change without something from which the change occurs.  The first requirement then is that there is a single defined plan of record.  That means there must be a single, agreed backlog which defines for the team the order of work. 

Communication and visibility is key. Everyone must be able to reference this ordered list to clearly see what is the agreed priority.  An ordered backlog will never be valuable if there are multiple versions of the data.  It will also not succeed if only some of the work is on the backlog.  If other work is managed by a different process there is no consistent view of priorities.  All work, whatever the source, must be consistently stored and managed in the team backlog.  This implies the rigorous use of a work management system.

All work, whatever the source, must be consistently stored and ordered
in the team’s backlog

Ruthless prioritisation

Whenever a new piece of work is introduced for the team, it must be added to the list.  And since the list is ordered, it must be placed at a specific position on the list.  This is a critical part of the process of managing work.  The discipline of assigning work at a point on the list creates much of the backlog’s value.  By choosing the position on the list (whatever decision making process is used) we are making two statements.

• The new work is less critical than the work above it.  Therefore it will not interrupt that work, which can continue as planned. 

• The new work is more critical than the work below.  Therefore adding the new work will necessarily delay that work.

Prioritisation really helps with communicating the consequences of any decision to introduce new work.  It is clear which items will be impacted and which will not. 

• Are there items which have commitments? 
• Are these items below the new piece of work? 
• What will the impact be on the commitments? 
• Are there commitments for the new piece of work? 
• What are the implications of completing the higher order items first?

The backlog will constantly be changing through backlog refinement. Typically a decision making process for reordering work at a Story level will be lightweight, while more process is needed when introducing new features which could disrupt future roadmap items.

Good Practices

As a leader you should ensure there is an ordered backlog for each team. Every team should be able to see a definitive, single record of the intended work. And that work should always be ordered.

For significant new pieces of work there should be an appropriate decision making process which ensures that the position of the work on the backlog is agreed and that the impact on other items is understood.

Every team should be able to clearly and unambiguously view their priorities