Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,459,377
Community Members
 
Community Events
176
Community Groups

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

Atlassian Community Events