Following on from my previous blog post about how to resuscitate a large poorly managed product backlog, the next stage is focused on defining a pragmatic model on which to structure agile backlogs.
General agile product management tutorials make reference to the ‘product backlog’ as a single entity – a rationalised and prioritised ‘to do’ list that encompasses all ambitions, wisdom and defects relating to a product. Yet as an American product manager friend of mine is fond of saying, “Trying to control a product strategy off a single list? Then you are running the business off the back of an envelope.”
If the ‘product backlog’ concept can be viewed as a general logical container to capture product ambitions and problems, then from a business process and product management perspective that simple single view has to be decomposed into a number of physical lists to make the concept workable. My own preference is to break the ‘simple’ logical product backlog into three physical backlogs: ‘strategic’, ‘tech debt’ and ‘client facing’. When you add the ‘current release backlog’ and ‘current sprint’ into the mix this makes the “Famous Five” backlogs referenced in the posting title.
Each of the ‘Famous Five’ backlogs has a distinct purpose and its own management process:
- Strategic product backlog – this is used to hold a list of all major innovation features/epics.
- Tech debt product backlog – this holds a list of all technical debt and QA debt, both large and small items.
- Client backlog – this holds a list of all defects and small scale feature requests made by clients, support and other stakeholders
- Current Release product backlog – this holds the list of epics, user stories and defects scoped for the current release
- Current sprint backlog – this holds the list of user stories and defects scheduled for completion in the current sprint.
Separating the logical whole into five lists makes the product management and planning process infinitely easier to control
It helps with content authoring, ownership and prioritisation. For example, the ‘tech debt’ backlog becomes the primary responsibility of the agile project team and associated technical experts. In a similar vein the ‘strategy’ product backlog is the primary concern of the product owner along side the product executive management.
The primary advantage of having separate product backlog lists is how it helps with the decision making process for two key product planning events:
a). Strategic planning.
Typically a product business will stage product planning and strategy reviews on an annual or semi annual basis. That planning process reviews the product in terms of its maturity, market position, success level and market opportunities. The primary outcome of that review is a new strategic direction (e.g. rapid growth, solidify success, horizontal expansion, stability, maintenance etc), where that direction is used to balance how much investment is to be allocated to support a progressive or defensive view of the product value proposition. Translating this into a practical context means that different proportions of the available investment will be committed to “innovation” (i.e. content from the strategic backlog), “incremental improvement” (i.e. content from the client backlog) and/or “tech debt” (content from the tech debt backlog). A product at the early stages of its life cycle is likely to have a high proportion of investment committed to ‘innovation’, whilst a mature product is more likely to be focused on ‘incremental improvement’.
Taking this approach a road map is crafted using the following main steps:
- A number of forward product releases are identified, usually around a time based model – quarterly or even monthly. For example, ‘R7’ for Q1 2017, ‘R8’ for Q2 2017 etc. This is the product planning horizon, and for most product organisations it translates into a rolling 12 or 15 month of product ambitions.
- Each forward product release will have a proportion of investment assigned to address innovation, incremental improvement and tech debt priorities. Those proportions can vary between releases.
- If a forward product release has investment assigned for innovation then the top most priorities from the strategic backlog are assigned to that release until the innovation capacity is consumed. On occasion innovation topics can require that one or more large scale tech debt topics be tackled as a pre-requisite. In that case the tech debt proportion may have to be increased to account for dependencies.
- Repeat the same top slicing process for the tech debt investment aspect, drawing the top priorities from the tech debt backlog into each release.
- Finally – and optionally – repeat the same process for the ‘incremental improvement’ investment proportion, drawing priority items from the ‘client’ backlog.
The last step – allocating client backlog content to the road map – is often excluded from the strategic planning process for two reasons:
- Client backlog content although important is not viewed as strategic (just BAU),
- Priorities for a client backlog can vary dramatically over time, so its often pointless trying to identify top client backlog priorities too far in advance.
However, if the product is at mature stage in its life cycle, or the strategic direction is more defensive, then it is likely that the ‘incremental improvement’ aspect will have the primary focus for continuing investment, and in that case outside of the next release the aim should be to identify themes from the client backlog (e.g. transaction performance, GUI stability) and associate those themes with releases outside of the next quarter.
b). Release planning.
Towards the end of the current release life cycle the product owner will start to firm up the scope/content of the next release, i.e. planning R4 before R3 is complete. By default the next release will assume the ‘innovation’ and dependent strategic ‘tech debt’ content defined in the product road map. After that the product owner needs to assess how best to ‘spend’ the investment proportion assigned to ‘incremental improvement’, alongside what’s left on the ‘tech debt’ aspect.
Notionally that step would be addressed by taking the top most priorities from the ‘client’ and ‘tech debt’ backlogs and assigning those to the next release, but there are a couple of preparatory steps that should be completed before then:
- Review current release ‘client backlog’ and tactical ‘tech debt’ related contingent/optional scope and assess delivery likelihood. It is highly likely that some low priority elements of the current release scope will not be completed. Now is the time to recognise that situation, pull the items from the current release, and slot them back into their appropriate backlog with a new priority.
- Consult with key stakeholders (sales, support) to ensure that any commercial commitments are suitably recognised in the client backlog
- Review client backlog priorities to get best value and avoid scatter gunning attention. A major limitation with drawing priorities from a simple one dimension list is that individual list item priority can lead to a fragmentation of effort across multiple areas. A more effective route is to try and identify common themes across all items on a list and to prioritise those themes. Focusing on a theme based view of priorities tends to deliver greater impact for clients, and those themes then become the focal points for sprints within a release.
Once these preparatory steps have been completed the ‘client’ and tactical ‘tech debt’ backlogs are in a good state from which to draw ‘incremental improvement’ scope. Take care not to over commit
Just like Enid Blyton’s fictional heroes, keeping the ‘Famous Five’ (backlogs) in mind will ensure that your (product management) adventures are both exciting and rewarding.