You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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.
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.
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:
Involve your team members to keep the backlog executable.
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.
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.