The Prioritisation Trap: Why Trying to Rank Everything is a Mistake
Most teams don’t have one priority – they have competing demands:
• New features – because shiny things keep the business happy
• Fixing old stuff – because past sins need atonement
• Keeping the environment strong – because broken pipelines don’t ship
• Ad hoc work – what I call Drive-Bys – when someone swoops in, dumps a task on your lap, and disappears
And yet, the mistake I see again and again?
Teams try to force all of these into a single prioritised list – as if deciding whether a database migration is more important than a login feature makes any real sense. The result? Endless debates, frustrated teams, and a backlog that feels more like a political battlefield than a tool for getting things done.
The reality is simple: you can’t prioritise unrelated work. No one can.
Selection vs Prioritisation: A Smarter Approach
Instead of pretending all work belongs in a single queue, split it into logical streams:
• New Features – the exciting, value-add stuff
• Fixes – technical debt and keeping things running
• Environment & Tooling – making delivery smoother
• Drive-Bys – unplanned, urgent, but inevitable
Once you do this, stop trying to prioritise everything against each other and instead use two separate policies:
1. Prioritisation Policy (Horizontal View)
Rank work within each stream:
• Which feature should come first?
• Which bug is most painful?
• Which pipeline fix has the highest impact?
2. Selection Policy (Vertical View)
Decide how much of each stream to take in at a time:
• Two features, two fixes, one environment task, one Drive-By
• Or shift the balance if something urgent comes up
This approach isn’t just more practical – it removes frustration and makes work manageable.
Why This Works
Instead of letting work get dominated by one category (hello, feature factory hell), this ensures a balanced, sustainable flow:
• New things get built
• Old things get fixed
• Drive-Bys don’t derail everything
And the best part? You can adjust the Selection Policy on the fly without the pain of re-prioritising everything.
• Big deployment coming up? Take fewer new features and focus on fixes or environment work.
• Crisis hits? Temporarily increase Drive-By capacity to manage urgent issues.
No endless backlog reshuffling. No constant firefighting. Just predictable, adaptable, business-aligned flow – without the chaos.
The Bottom Line
If your backlog feels like a never-ending argument, stop trying to rank everything in one list.
Instead, separate, balance, and adjust as needed.
Common sense? Yes.
Surprisingly rare? Also yes.
Would love to hear how others deal with this – how do you balance competing work types in your teams?