October 20, 2021

How to build an executable backlog?

Agile Roadmapping Project Management WBS & Backlog Structuring
BigPicture Team

What is an executable, or healthy, backlog? While projects have (relatively fixed) scopes, products and agile teams have (living) backlogs. Some backlog items will never make it to the market, and that is fine. An executable backlog excels at pushing the most value-adding items up, as new information arrives. As a side effect, blind alley items get killed. How to maintain a backlog executable and healthy?

What is a backlog?

Backlogs are artifacts of agile product management. The backlog converts a high-level vision into the working details. As far as the software tools are concerned, the vision of the product is represented in the roadmap, while the backlog normally accompanies an agile board as is the case in figure 2.

Figure 2. Backlog in the Board module of BigPicture Portfolio Management software.


Where do backlog items come from? Vision and strategy are obvious sources. However, customer requests, user surveys, QA/Sales/R&D/Customer Support teams’ insights, press reviews, or even a threatening competitor prevail in products that are past their infancy.

High-priority items appear at the top of the list, and the less important ones are at the bottom. The lower an item sits in the backlog, the less likely it will ever make it to the development stage. Even more importantly, the items and their order in the backlog are constantly changing – hence the living backlog.

How to build and maintain an executable backlog?

There are two prerequisites for an executable, healthy backlog.

The organization must have a strategy or vision of the product.

And somebody must own the backlog – ideally a qualified product/project manager. Other than that, here are crucial steps to keeping the backlog executable:

  1. Have a strategy-level tool on top of the backlog – ideally a Roadmap in agile product management; or Gantt chart in hybrid, predictive project management.
  2. Rather than preventing more items from making it to the backlog, let the prioritizing process do the filtering. Use exponential numbering, for instance 1, 3, 9, 27, for grading items in the backlog, whatever the prioritization criteria are.
  3. Keep distant future items general. Increase the level of detail for high-priority items. Invest time in writing descriptions only when items approach the development stage. Prepare a few sprints worth of user stories ahead of time.
  4. Refine the backlog. Rank, illustrate, size, and split user stories. Revise and re-prioritize the backlog periodically. Rather than on sentiments, base your decisions on data (potential revenues, upvotes by customers, time/story point estimates, costs, risks).
  5. Deliberately choose between estimating in time units and story points.
  6. Consider splitting the backlog into two, or even three lists:
  • long-term, big picture backlog (product backlog)
  • release backlog (optionally)
  • short-term, executable sprint backlog – for one or a few sprints

7. Sweep ‘Done’ tasks away by archiving them. This way the backlog is kept tidy, and the ‘Done’ tasks are still available for the retrospective and KPI measurement.

8. Excise items that no longer match the latest product and business strategy.

Employ teamwork. Involve team members in keeping the backlog executable.

Benchmarks, best practices

Those steps will likely lead to the executable backlog.

But there are even more specific benchmarks:

What “units” to use in the backlog? Product managers commonly utilize Features, Requirements, and Use cases – in the “master” backlog. The Sprint backlogs normally see more granular Epics, User Stories, Tasks, and Sub-tasks.

What makes a properly sized Feature? The implementation of a properly sized feature should take anything from a couple of days to one Sprint (two weeks). Features that require several Sprints, are highly complex, and thus, riskier.

The backlog can include technical debt-related items.

Up to 10 percent of a team’s sprint capacity can be allocated to backlog refinement.


If an eureka moment is 100% then the implementation of the triumphant discovery rarely produces more than 30% in a marketable product or service. Similarly to a novelist and the publisher, the backlog forces a visonary to put the idea down on paper and verifies the feasibility of the out-of-thin-air inspiration.

The executable backlog entails two things: applying units – time, complexity, money – and grading the items in the backlog. And, coming to terms with the fact that selected backlog items will never make it to the market.