The other day a product owner colleague asked me for some suggestions about how to wrestle control over a large agile software product backlog that they had inherited.  The backlog had 300+ items, with entries going back over multiple years.  This triggered some thoughts about how backlogs can get to such a size,  the purpose and life cycle of backlogs and a method of how to get things back into order.

So what has this got to do with asking a stranger for directions?   When considering the wider problem I was reminded of the old joke about a tourist stopping a local resident to ask for directions to a famous landmark, where the local replies, “”If I were you, I wouldn’t start from here”.   The point being that the backlog itself rarely holds the the answer to how you go about rationalising it.   Backlogs tell you more about where a product has come from,  rather than the way ahead.  What’s missing is the strategic direction from stakeholders, product owners etc about the future business, market and client imperatives that should be driving backlog content and prioritisation.  Without that top down direction shuffling a product backlog is like compiling a to-do list without any notion of who the list is for.


A product backlog is not a ‘bucket list’.  It has a business function to capture the activities that are realistically addressable within a product planning time horizon.  That horizon can vary according to type of product and the state of its market, but its a sure bet that for most products these planning horizons are shrinking to a point where anything more than 9 months out is pure fantasy.  The pragmatic reality behind this approach is that any small scale enhancement or defect that cannot be addressed within that product time horizon simply has no place on a product backlog.

So the first priority in determining what to do with a very large large backlog is to define that forward strategic direction.  Broadly speaking this is a product life cycle question that’s going to boil down to a ‘progressive’ versus ‘defensive’ posture based upon the parent organisation’s view of the products “success” and upcoming market opportunities.  I’d offer five main options:

  • ‘Bold growth’ – the product owners want to ‘move the needle’ by making significant steps forward by adding major new capabilities or pivots into new areas.
  • ‘Conservative growth’ – this is about reinforcing existing product strengths, whilst mitigating product weaknesses
  • ‘Stability’ – is normally about protecting existing product market share,  minimising cost of ownership etc – a defensive strategy.
  • ‘Essential repair’ – this is generally associated with a ‘failed’ product, but one that has important clients and/or long standing open work commitments.  Although the business might want to put the product into ‘essential maintenance’ mode various economic pressures require a measure of continuing investment to stabilise the product so that it can meet predefined expectations/commitments.
  • ‘Essential maintenance’ – this is for mature products at the end of their life cycle, and is about minimising future investment in the product so that current operations may continue.

With a progressive strategy it is likely that large parts of the existing backlog will not be carried forward.  In contrast a defensive strategy will probably seek guidance from the distilled essence of what the backlog represents.

One word of caution when assessing a large product backlog.   Backlogs become large because they have not been actively ‘curated’, and my experience of these backlogs is that they are usually in a pretty poor state when it comes to integrity of the data and content categorisation.  The ‘bold growth’ strategic option might allow you to discard most of the existing backlog (may be) but for the other choices my view is that they do require a detailed study of what the backlog represents.  With a large backlog it could take a considerable time to complete that detailed review (i.e. 350 items @ 2 minutes an item = 12 hours = 2 working days), and for those who declare that they haven’t the time to spend on such an exercise, I would would argue that this further evidence of a lack of will to curate the business problem.

It is possible to take a more brutal top down approach – i.e. start off by closing all backlog tickets that are older than 9 months and/or at low severity levels – but you had better be sure about the integrity of the backlog data before taking such a sweeping action.  As a precaution run some tests on a sample.  I can pretty much guarantee that the sample outcomes will not be good, which to my mind will force the product owner to take on the full detailed backlog review.

A full detailed backlog review is completed in two stages:

  • Cleansing the backlog and categorising the content.
  • Rationalising the cleansed content to ensure that it fits the product planning horizon

The first cleansing stage requires a little preparation, which is about ensuring that the categorisation step can be achieved quickly and easily.  To make sense of a linear list it helps to have a clear view of how a backlog item is linked to different areas of the product, its impact and  nature.   This involves:

  • Compiling a master list of product ‘components’ or ‘subject’ areas. This is equivalent to a topographical view of the product and might equate to individual services, main web UI views or key transaction types.   The idea is that a backlog item can be associated with one or two components.  Some backlog items might be very general in nature , so make sure that your component list includes a ‘General’ entry to catch these rare situations.  Some products may already have a ‘component’ list, but this should be reviewed to ensure that the contents are up t to date and relevant for the purpose of this exercise.
  • Refresh the definition of defect severity.  To properly categorise defects it is important for the reviewers to have a clear view of what the ‘severity’ ratings represent.  Typically severity is expressed as a code from ‘S0’ (critical) down to ‘S5’ (low level nuisance).   Severity categorisation is about quantifying the impact to business process completion.
  • Item type – usually a well managed backlog has just two issue types – ‘defect’ or ‘feature request’. However, for this type of backlog recovery review exercise I find it helps to group items into one of six categories, because an un-managed backlog is going to have instances of all six:
    • ‘Defect’  – a problem with how an existing process completes
    • ‘Feature request’ – an enhancement to an existing process or new feature idea
    • ‘MI’ – any backlog item that is associated with new reports or surfacing new management information
    • ‘Support’ – any backlog item that is linked to helping the support function, or lower cost of ownership
    • ‘Tech debt’ – architectural or process efficiency refactoring work on an existing product area.
    • QA – a backlog item that represents QA work to complete on a component/subject.

The basic idea is to tag each backlog item with its associated components,  the correct severity, and the right item type.  The goal is to produce the summary shown in the spreadsheet mock up set below:


The cleansing stage is best performed over a number of sessions.  Give each session a target of reviewing ‘x’ number of backlog items.   The session participants should include the product owner,  scrum master/project manager, key members of the product team, and any important item authors – i.e. staff from support that have posted a lot of backlog items.  The product owner is best placed to run the session and ensure that the time on each item is strictly controlled, e.g. at this stage no more than 2 minutes on each item.

The review process for each ticket involves the following steps and should involve all participants:

  • Quickly review the item title and any supporting narrative.
  • Is the item understandable?  If the group can’t make sense of it, then mark the item as ‘closed/can’t replicate’
  • Is the item still relevant?  Large poorly managed backlogs are going to have quite a few old entries that are simply no longer relevant.  If this is the case mark the item ‘closed/no longer relevant’
  • Is the item already fixed?   it’s not uncommon to find lots of items that are already done.  In this case mark the item as ‘Closed/validate fixed’
  • Is it an obvious duplicate?  Over an extended period it is not uncommon for the same issue to reported in multiple ways.  In this case mark the item as ‘closed/duplicate’
  • Set item type – review the item purpose to assign it the correct type, either: ‘Defect’, ‘Feature Request’, ‘MI’, ‘Support;, ‘Tech debt’ or ‘QA’
  • Set defect severity – if the item is a defect review its context to ensure that it gets the correct severity rating.
  • Set item component.  Choose one or more of the components/subjects to which this  item is related.  Use the ‘General’ component sparingly.

It is quite common for this first cleansing stage to reduce the initial backlog by anything from 30% to 50%.

The second ‘rationalisation’ stage is about applying the chosen strategic direction to the remaining backlog content and has the following main steps:

  • Rationalising/clustering issues that share a common cause.  With a large un-managed backlog it is quiet common for variations on the same problem to be reported. These are not so much duplicates as just different symptoms of the same underlying problem. Such items can be merged into a single item.
  • Assessing QA –  it is a common habit for teams to add backlog entries for QA work left over on notionally complete work items.  The product owner has to assess how relevant these QA items are now.  If the related component has a low defect count then on the basis of “if it ain’t broke, don’t fix it” the QA work might be desirable but not essential.  The product owner can close these items, but any that remain should be prioritised to the top of the backlog.
  • Assessing tech debt.  Most technical debt issues relate to tech implementation or architectural constraints that impact the non functional aspects of a product – like scalability, throughput, resilience, concurrency etc.  From a product owner’s perspective this a market/economic question. For instance, does it matter that the product can only support up to 500 concurrent users?   Tech debt issues should be closed if there is no realistic prospect of them being addressed within the planning horizon.  Those that remain should be set at the very top of backlog priority list.  That’s a sobering fact for the product owner to weigh,  and they will have to assess the tech debt resolution gains against the opportunity cost of addressing other topics.
  • Assessing Support.   Tickets associated with support function requests or cost of ownership are often overlooked and yet in many ways are the easiest category to prioritise.  Each issue should have an associated business case in terms of frequency, cost and service disruption. Only keep the item if the business case is tangible.
  • Assessing MI.   Capturing ‘MI” issues separately is important as products can be relatively successful in terms of their core functional purpose but fail to surface sufficient business value due to a lack of reporting or MI features.  Issues associated with MI can often be aggregated into a common solution (e.g. a common data model that can serve multiple reporting requirements), also its much easier to outsource MI work so product team resource constraints may not necessarily apply.
  • Component relevance/ranking.  Rank the components by their importance/relevance to the strategic direction.  Starting with  the bottom ranked /least relevant components review the tickets associated with that component and assess whether there is any realistic prospect of them being addressed within the planning horizon.  If not, then mark them as ‘closed/won’t fix’.   Equally if the strategic direction requires a new approach or reworking of an existing component then its probably OK to close all issues associated with that component.   Keep chipping away at the peripheral components until only the core components that deliver the most business value remain in scope.

Completing the steps outlined above will dramatically shrink the backlog size. Without getting fixated on a number the goal should be reduce the overall backlog size to less than a 100 items, perhaps 150 items – that depends very much on the product scale and maturity.  This second stage may entail several iterations,  as the impact of accepting required tech debt, QA and support work items has to be balanced against market/customer expectations for new features.

In summary…

If you are a product owner who has inherited a large poorly managed backlog there is in my view no real alternative to completing a detail reviewed of the backlog contents.   However,  there is little point starting this backlog recovery process until the forward product strategic direction is agreed.  Much like the tourist in my opening story you need to understand why and how you intend to travel to the landmark before you ask for directions!