How to build an executable backlog?

How-to-build-an-executable-backlog-1.png

Products and Agile agile teams have (living) backlogs.  They are constantly changing and adapting, therefore some items may never hit the market. That's because an executable backlog works well in pushing the most value-adding items up as more information appears, resulting in blind alley items elimination. 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 1.

Backlog in the Board module in BigPicture.png

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

Where do backlog items come from? The primary source is vision and strategy. However, new items may be based on various sources like 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.

Product backlog items are prioritized; high-priority items appear at the top of the list, and the less important ones are at the bottom. The lower the 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 preconditions for an executable, healthy backlog.

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

And backlog owner – ideally a component product/project manager. Furthermore, 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. Groom (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. Read more: Story points, hot or not?
  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.

Involve your team members to keep the backlog executable.

Benchmarks, best practices

The listed above will likely lead to the executable backlog.

But there are even more specific benchmarks:

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

What makes a properly sized Feature? 
Each feature you add to your backlog takes time to implement, and the implementation of an adequately sized feature should last 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.

Conclusion

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 covers two matters: 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.

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events