From Chaos to Flow - Part 2: Designing Your Backlog for Real-World Product Delivery
Real product delivery needs one backlog that holds everything, e.g., programmes, tech debt, bugs, small change, prioritised by outcomes, not categories. Discovery and delivery must stay visible together to protect flow and keep teams moving without randomisation.
Signal Boost: “One”, U2
It is not about how much work you have. It is about how you hold it together.
One Backlog to Hold It All
If you want real product flow, you need one backlog.
Not a programme backlog over here. Not a tech debt list hiding in someone's notebook. Not a bug tracker nobody looks at until it is too late.
One backlog. One view of all work. One truth about your product's reality.
What the Single Backlog Holds
A real-world product backlog holds:
- Funded programme demand
- Small change
- Tech debt remediation
- Bug fixes
- Platform resilience work
- Platform capability growth
All in one place. All prioritised together. All competing honestly for capacity.
How to Structure It Without Losing Your Mind
1. Use Work Item Tags, Not Separate Backlogs
Instead of separate backlogs, use tags or fields to mark:
- Work Type (Programme, BAU, Bug, Tech Debt, Platform Improvement)
- Work Stage (Discovery, Shaping, Delivery, Adoption)
This keeps everything visible without fragmenting prioritisation.
2. Prioritise Outcomes, Not Categories
Do not let funded programmes automatically jump the queue.
Every item must be shaped enough to compete based on:
- Value
- Risk reduction
- Urgency
- Readiness
Programme work can dominate, but only by design, not by default.
3. Protect Capacity for Tech Debt and Bugs
Reserve around 20% of delivery capacity every sprint for:
- Tech debt paydown
- Bug remediation
- Platform health
Do not make it a wish list. Make it part of sprint planning. Make it visible.
If you do not protect platform health proactively, you will pay reactively later.
4. Make Discovery Work Visible
Discovery is not a phase. It is live work that deserves visibility.
Tag discovery items clearly and treat them as first-class citizens in the backlog. If discovery is hidden, delivery eventually dries up.
Real-World Example Layout
| Field | Example Values |
|---|---|
| Work Type | Programme, Small Change, Tech Debt, Bug, Platform Improvement |
| Work Stage | Discovery, Shaping, Delivery, Adoption |
| Outcome Area | CRM Capability, Web Experience, Communications & Docs |
A backlog that breathes. Not a backlog that hides reality.
What It All Comes Down To
One backlog does not make work simpler. It makes work honest.
When you can see all the real demands on your teams — funded, unfunded, urgent, important — you can finally make smart, painful, courageous decisions.
Real product flow starts with real visibility.
In the next post, we will map the natural flow of work from idea to outcome and why shaping work properly saves teams from randomisation later.
Next Up: Part 3: The Continuous Flow from Idea to Value.
Real product flow moves from intake to adoption through shaping and discovery. Shaping early protects teams from random delivery chaos.
