What is prioritisation?

Prioritisation is even more central to Agile than to other lifecycles and methodologies: story priorities are constantly under review, and they are used to make the most serious decisions.

As in any other methodology, the purpose of prioritisation in Agile is to decide the order in which work will be done. That is, prioritisation defines how urgently a backlog item needs to be delivered.

Why is Agile prioritisation so different?

Prioritisation is an important tool in any lifecycle or methodology. How it is used by each type can be very different, however.

In a more traditional (e.g., waterfall) approach, once the prioritisation has been agreed, it is generally fixed:

  • Prioritised items become ‘approved requirements’ that, once implementation has begun, are generally treated as equal in priority.
  • Priorities are formally authorised by senior management operating outside the implementation team, and it requires their authority to change them.
  • Priorities can only be changed through a formal change control process.
  • Priorities can’t be altered by the implementation team, either to suit the implementation plan better or because experience is showing that the item is not what it appeared to be when its priority was first agreed.
  • Priority is often driven by major cultural and political struggles.

So in more traditional approaches, priorities tend to remain more or less static, or change for reasons that have little to do with the implementation process.

Agile is different:

  • The priority of work items is expected to change as experience and knowledge accumulates.
  • There are regular ‘ceremonies’ at which priorities are reviewed and, where necessary, changed.
  • Priorities can be – and routinely are – challenged by the team at any time.
  • Once implementation has begun, changing priorities is an informal process – the team and Product Owner simply agree to the change.

This is made possible by Agile’s radically different delivery strategy.

  • A traditional project or programme is usually months and even years long, with nothing being delivered until the very end of that time.
    • So it is vitally important to stakeholders to make sure that their requirements are assigned a high priority.
    • This makes prioritisation a ‘life-or-death’ process for both the stakeholders and the team.
    • So prioritisation is subject to heavyweight controls and high-level decision-making.
  • In Agile, by contrast, if a story is reprioritised, this is seldom a crisis.
    • Even if reprioritisation means that a story is dropped from the current iteration or release, it will usually be moved to the next ‘window’ – usually delaying it by a few weeks at most.
    • There is also the expectation that, if an item is reprioritised, this is only done to ensure that other items are more likely to be delivered as expected. So the net outcome is positive.

The principles of Agile prioritisation

The principles of Agile prioritisation can be summarised as follows:

  • Priorities should always be as accurate as possible, but only as precise as they need to be to make the decisions they currently need to support.
    • For example, it generally takes less precision to decide whether a story is important enough to include in a release at all than to prioritise it within, say, an iteration.
  • Priorities are never final.
    • Prioritisation is never completely finalised until the backlog item is delivered.
    • However, for the purposes of the current round of prioritisation, it is complete enough when the team is confident that their prioritisations are good enough to let them begin the next stage of work.
    • Priorities cannot be finalised early because the information needed to finalise them is never final:
      • The closer the story comes to being implemented, the more will be known about it.
      • Even when implementation is under way, changes may occur that affect priorities.
  • Even if they are not actively changed by experience or events, all stories should have their priority confirmed at least once in each iteration, typically during Backlog Refinement.
  • An order of priorities is not a contract. It’s a best guess.
    • As with estimates, treating priorities as commitments will not make delivery any faster, but it will:
      • Force the team into a sub-optimal implementation cycle.
      • Drive up technical debt.
      • Undermine the prioritisation process.

How does prioritisation work?

Overview of the prioritisation process

To set priorities, the relevant people need to:

  • Define how valuable or otherwise important a backlog item (idea, story, etc.) is to the affected users, customers, Product Owner or other stakeholders. This gives a crude model of priority.
  • However, the context in which implementation will take place also needs to be taken into account. This will create a more subtle, detailed and realistic picture of how the work could or should be done.
  • Based on this information, the importance or urgency of backlog items is optimised. This decides the item’s priority.

Grounds for prioritisation

There are many reasons for a story to have a high or low priority. These reasons need to be assessed and re-assessed for each backlog item, especially when the delivery process is not going quite as planned or stakeholders begin to see their own stories differently.

This becomes especially clear when re-prioritising an already prioritised backlog. During that process, ask yourselves:

  • Will the item still deliver the same absolute value as before?
  • Will the item still deliver the same value, relative to all the other items in the backlog?
  • Has the item’s place in the Product Vision or roadmap changed?
  • Have new items appeared that push this item off the list of most-valued items?
  • Does the user still want this item as much as when it was last prioritised?
  • Although the item is  just as valuable in itself, has the the user-base that wants it changed?
    • Has it shrunk or grown?
    • Has it importance to your stakeholders changed?
  • Will the value of this item (or a significant part of it) be delivered by some other combination of changes, so that, by itself, this item adds less value?
  • Will it be significantly harder (or easier) to deliver this item than previously expected?
  • Will it be significantly more (or less) risky to deliver this item than previously expected?
  • Have team changes also changed how easily or cheaply the item could be delivered?
  • Was your previous estimate just wrong, and delivering this item will be much harder (or easier) to deliver than you previously thought?

Although it can be useful to have a checklist like this when you first begin prioritising your backlog, the question it asks will will soon become much more intuitively obvious as the team gains experience.

Who performs the prioritisation?

The previous section referred to ‘the relevant people’ being responsible for prioritisation. At each level it is important to make sure that:

  • The right kind of information is available.
  • The right authorities set priorities.
  • The right areas of expertise is applied.
  • The right level of precision is achieved.

So the choice of who sets priorities is critical.

Who the right people are depends on where the item being prioritised is in its own lifecycle:

  • When the work item is first included in the backlog, its initial priority will be decided by the Product Owner in consultation with the other stakeholders who are concerned with this product.
  • Once the work item has been assigned to a particular release, the Product Owner will also assign its priority within that release, in consultation with the Agile team who will be responsible for implementing it.
  • Once the work item (by now converted into one or more stories) has been assigned to a particular iteration, it is prioritised within the iteration by the team, in consultation with the Product Owner.

When does prioritisation occur?

Prioritisation is a recurring activity:

  • Items should be prioritised as soon as they are recorded in the backlog.
  • There are also standard Agile ‘ceremonies’ at which priorities are reviewed.
  • Between these events, priorities can be changed at any time, depending on  new conditions, information, feedback, etc.

Simple prioritisation methods

Agile has borrowed or evolved a number of prioritisation methods, which are described below. Agile teams should expect to use all of them at one time or another.

Value-based prioritisation

This is the most obvious approach, though it’s slightly more complex than it looks. Here prioritisation is based on the value of the item. But it’s not just value – it’s value for money – which is to say, the largest return on investment. This ratio of cost of delivery to value of the deliverable then gives a more sensitive index of priority.

Simple though that sounds, there are still other complicating factors that may influence priorities.

  • Although Agile always strives to minimise the dependencies between items, they are often hard to remove completely.
    • These dependencies often mean that, however valuable item A may be, it gets a lot of its value from item B already being in place – even though B, by itself, isn’t of much value. Item B might be a technical or architectural improvement, for example, or something offering strong synergies with item A.
    • So do you do A first, or B?
  • ‘Value’ generally means value to the user, but increasingly value to the business or organisation is being used.
  • The number of and types of users, customers and others that will benefit from this item should be included in this value.
  • Unusual issues and risks may also influence prioritisation.
  • An item’s opportunity costs – what could have been done with the same resources – should also be taken into account.

How many such factors need to be taken into account and how important each one is depends on the organisation and, to some extent, the Agile team. Often it will come down to who has the most leverage (the business? the customer? the CFO?) and the kind of environment the team and organisation inhabit.

Burning platforms

A ‘burning platform’ is a problem – a gap, a failure, a crisis, etc. – that is happening right now, and it is a problem that is perceived as both serious and urgent enough to need dealing with immediately. So the reasons for dealing with it are obvious and agreed.

The idea of a burning platform began from the idea of a sudden disaster – literally a burning oil drilling platform. However, it’s been generalised to the idea that prioritisation should be based on the amount of pain a problem is causing, rather than, for example, its calculated value.

The idea of identifying burning platforms is basically another ‘triage’ method, in which you divide work items (stories, features, bugs, etc.) by their urgency. In descending order of priority:

  1. Is the pain being felt right now?
  2. Will it be felt within the current release/iteration timescale?
  3. Will it be felt ever, even if we ignore it completely?

Once you have answers to these questions, the priority can seem obvious, especially to those who are feeling the pain directly. However, there are at least two major difficulties with prioritising by pain level.

The first is that it is wholly negative. Prioritising by pain level works when the work is designed to fix problems or where value is being lost. But there is no way to identify or evaluate new options or capabilities that would add value.

The second problem is that the sense of urgency (perhaps even panic) associated with burning platforms can overcome rational planning. When that happens, the urgent always takes priority over the important, yet it is not clear why.

So someone always needs to ask, Why is this burning platform, dramatic though it may be, a higher priority than the other things we have already decided are important? Why is removing this pain more important than adding this pleasure (e.g., a new capability, improved performance elsewhere, etc.)? In terms of the above list, even if the burning platform is a problem ‘right now’, is solving it more valuable than delivering something else – something already on our list?

This is a difficult and often highly political question, but it is essential that it should be asked. If it isn’t, panic and impulse will replace real management and leadership.

Complex prioritisations

Sometimes it is very hard to prioritise a story clearly – for example, when different scorers prioritise it differently.

  • Sometimes this reflects the fact it is not in fact a single item (e.g., it is an epic rather than a story). In that situation, consider dividing it into several distinct stories. (See Epics for methods.)
  • In other situations, the conflict is genuine: the story really does have different values for different groups.

In the latter situation, using a slightly more sophisticated prioritisation method can remove the difficulties. Several such methods have been developed, and are described below.

Note that complex prioritisation problems tend to appear early in the delivery process. It can be hard to choose between high-level ideas, epics and major features, which tend to be rather shapeless and difficult to evaluate. It’s usually much easier to prioritise individual stories, which are generally much simpler and easier to envisage and compare. So few of the details of what follows should apply once your overall Release Plan has been agreed.

Using a decision matrix

The ‘simple’ method described above is well suited to a situation where a small number of participants are prioritising relatively simple work items. In that situation, prioritisation is an almost intuitive activity.

In a more complex situation (e.g., where the ‘product’ serves many groups or prioritisation needs to take several criteria into account), a more sophisticated but still manageable technique is needed.

A widely used method is the ‘decision matrix’. This is a tool for prioritising multiple alternatives (e.g., stories) using two or more criteria. The Pugh Matrix is a widely used example.

Pugh Matrix

Pugh Matrix

Once the basic spreadsheet has been created, the steps to creating a Pugh Matrix are simple:

  1. List the stories (or ideas, features, epics, etc.) you want to prioritise across the top row, in the ‘Backlog’ section.
  2. List the criteria by which you need to decide in the left-hand column, under ‘Criterion’.
  3. Agree a weighting for each criterion:
    • This is a score showing how important it is, relative to the other criteria.
    • These weightings should be agreed by all participants in prioritisation.
  4. Taking each story in turn, score it against each criterion.
    • Ideally the stories should be scored in random order.
    • The final scores must be agreed by all participants in the prioritisation process.
  5. The totals for each backlog item are then calculated by multiplying its score against each criterion by the weighting for each criterion.
    • In Excel you can speed this up by using array calculations or the SUMPRODUCT function.
  6. The stories are then prioritised in order of their total score.

Bucket prioritisation

In principle Agile expects each story to be individually ranked. This makes it easier for the implementation team to decide which items to work on next. But sometimes it is unrealistic to rank individual items – sometimes because they are too similar, sometimes because they are too dissimilar, and sometimes because the complexity of the factors that need to be taken into account makes it impractical to choose between individual items.

When faced with this position, a ‘bucket’ approach can be used instead. These techniques don’t aim at ranking individual items, only at assigning them to large groupings. These allow individual items to be included or excluded in bulk. It is a useful technique, though it has its own complications.


On the surface, this is too simple a method to need much explaining – surely it is self-evident?

  • High – the ones we definitely need to do.
  • Low – the ones we definitely don’t need to do.
  • Medium – the rest.

Early in the lifecycle of an idea, it is usually easy to allocate it to one of these categories. At that stage, the question is really, ‘Is this item interesting enough to work on further?’

Later it becomes more difficult.

As with any ‘triage’ (three-level) system, the hard part about High-Medium-Low is in deciding where the boundaries lie. Triage originated on the battlefield, where doctors needed to make a simple if grim choice:

  • Which casualties will recover without treatment?
  • Which casualties will only recover with treatment?
  • Which casualties will die even if they receive treatment?

In this situation, it is the middle band that receives treatment. But that still leaves the life-or-death question of how bad is so bad that the casualty should simply be left to die? The closer one gets to this boundary, the harder it is to define.

In the less dramatic world of Agile and High-Medium-Low prioritisation, the problem is essentially the same: defining the middle band.

  • Unless scores are defined objectively, individual scorers can still introduce their own subjective biases, preferences and agendas.
  • Even without attempting to introduced their own viewpoints, individuals interpret the same criteria very differently.
    • Different scorers may (and in fact probably will) use different assumptions or methods.
    • There is also evidence that different scorers give systematically higher or lower scores than other scorers to the same items, even when applying identical criteria.

And so on. What appear to be clear definitions are often highly subjective or ambiguous. The same applies to terms like ‘significant impact’, ‘large value’ and so on – in the absence of an objective scoring method, an illusion of precision is created.

Yet High-Medium-Low remains a useful technique, especially as a preliminary filter.

  • Firstly, judgments balance out across groups, so when a group assigns priorities, individual biases and preferences  matter less.
  • Secondly, if there are items everyone can agree are either High (definitely do it) or Low (definitely don’t do it), identifying them quickly frees the prioritisation team to focus on the hard problem – the ambivalent items in the middle.

MoSCoW prioritisation

Another widely used bucket method is ‘MoSCoW’ prioritisation.

Although MoSCoW criteria are less ambiguous than the High-Medium-Low categories, they are still open to subjective influences. But as the following sections show, MoSCoW is valuable in other ways too.

Defining MoSCoW priorities

MoSCoW prioritisation is so called (and written in that strange way) because it is based on a simple model of four priority levels:

Priority levelInterpretation
MustThe work (iteration or release) will be a failure if this item is not implemented.
ShouldIf this item is not implemented, the Product Owner or stakeholders will be disappointed. It will not however be a failure.
CouldInclude this item if there is otherwise unusable spare capacity.
Won’tThis item has been considered but will not be implemented (for now).

Multi-level MoSCoW prioritisation

One reason why MoSCoW is valuable is because it deals with both aspects of a work item’s priority:

  • How important is this item?
  • How urgent is this item?

That is, even though a story may be very valuable, it doesn’t necessarily have to be implemented as soon as possible. For example, a product aimed at a very seasonal market (e.g., summer holidays) may not be exceptionally valuable, but it may lose all value if it is not implemented in time for its market. So it may be sensible to implement it early, even at the expense of what is, in general terms, a more valuable story.

Another way of thinking about this situation is to say that a story has several priorities – one each at product, release and iteration levels. So a story may be an essential part (a ‘Must’) of the Product Vision, but it may not be critical that it is implemented in the current release (i.e., a ‘Should’), and even less important that it should be implemented in the current iteration (a ‘Could’).

A work item that is not meant to be implemented until much later in the product’s lifecycle could even be a ‘Must’ for the product but a ‘Won’t’ for both the current release and iteration!

Using MoSCoW to design flexible backlogs

A useful principle of MoSCoW prioritisation is that the items included in an iteration or release should not all be of the highest priority – they should not all be Musts. The bucket needs to be filled with a mixture of priorities. This is because:

  • Needs  and conditions will change as the work proceeds, and it may become necessary to include new high-priority items (i.e., more Musts).
    • If that happens, what will be dropped? If the iteration backlog is already made up solely of other Musts, there’s no basis for identifying what can be taken out to allow the new story to be included.
    • If, on the other hand, nothing can be dropped, then either the ‘bucket’ is overfilled (with the usual effect) or the release or iteration will be considered a failure, because it did not deliver this Must.
  • Other changes also happen – a story takes longer to complete than expected, so something will have to be dropped.
    • Again, in an iteration backlog made up solely of Musts, what should be dropped? All Musts are equally important, so the bucket overflows again – this time because of the extra effort needed to do the same work.
    • This violates the Agile principle of maintaining a sustainable pace, and threatens both the team’s ability to deliver the rest of the iteration or release and its overall productivity.

So a backlog should always include a mixture of Musts, Shoulds and Coulds. Coulds and even Shoulds can then be sacrificed for higher priority items. In this way, flexibility is built into the backlog.

Other prioritisation considerations

Local versus global priorities

A major prioritisation issue for many organisations is balancing local and global decision-making. In most organisations, global projects and programmes tend to have priority over local priorities. They are after all more likely to have a strategic impact, and their stakeholders also tend to be more senior.

This can be very frustrating for local groups (e.g., individual business units, internal functions such as HR or operational areas), who can find that their work is never judged important enough to be included in Release Plans.

At first sight, the solution adopted by many organisations does not seem to be to adapt the prioritisation process. Instead they change the way budgets and resources are allocated. That is, they allocate a part (e.g., 25%) of the available funding to locally defined work items, to be decided by local groups based on their own interests. But this, of course, is just an indirect way of managing the underlying prioritisation problem.

In principle this should not be an issue for Agile teams. A basic assumption of Agile product ownership is that there is a dedicated product budget and a specialised product team. However, this assumption is not always met, and Product Owners & teams may still find themselves competing for funds and resources.

Where this is the case, a formal allocation of part of the global budget (and therefore the power to prioritise local work) can be a valuable contribution to Agile prioritisation, and Agile product management generally.

Auto-escalating priorities

Another source of frustration is the fact that low priority items can remain in the backlog for years without ever rising high enough to actually be implemented.

In this situation, some organisations adopt a self-prioritising approach to old work items. As each new round of prioritisation takes place (in Agile, at least in each round of Release Planning, and usually much more often), the priority score of stories that were already in the backlog (or perhaps only stories over a certain age) is automatically raised by a fixed amount.

As a result, even very low priority items will be implemented eventually.

Like balancing local and global priorities, auto-escalation is fundamentally a cultural or political tool, aimed at managing the organisation (and potential conflicts) rather than the work itself. From a purely business or functional perspective, a low priority should mean that the work will probably never be done.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?