Home → Part 02
Backlog Refinement: Kill Bad Ideas Early
Refinement is a funnel, not a ceremony. And that funnel does not start in the meeting room — it starts the moment an idea is born.
- Filter first, detail later. Kill a weak idea in two minutes with maths that fits on the back of an envelope.
- This is product work. Pulling engineers into the filtering session produces meeting fatigue; only mature items should reach them.
- You need one currency. Compliance, revenue and cost-down work can only be compared once they are all expressed as profit.
- Equal ROI? Take the smaller one. Shipping earlier pulls the return forward and teaches you the real risk — the customer's reaction — sooner.
The ceremony theatre problem
In most teams refinement is an hour spent reading items off the board. Everyone attends, nobody speaks, and no item is dropped. That is not refining, it is reading aloud.
The real job of refinement is not to polish items but to discard most of them. Of a hundred ideas entering the top of the funnel, perhaps ten should reach the team. If nothing is being discarded, you do not have a funnel — you have a pipe.
Developers and QA are not in the filtering stage. Refinement is product and business territory. The only outcome of dragging the engineering team in is that hours which could have been spent building are spent in a meeting.
My own exception: when an idea's value depends entirely on technical feasibility ("is this integration even possible?"), ask one engineer for ten minutes on that one item. Do not invite them to the whole session. The difference: the engineer is a consultant here, not an attendee.
1. The first filter: back-of-the-envelope math
You do not need a detailed report to know whether an idea makes sense. A rough calculation that fits on the back of an envelope and takes a minute or two is enough: how many users, how often, how much gain or saving?
If that calculation does not say "there is something here", do not spend one more minute on the idea. Every piece of junk that survives this stage turns into a compounding cost later, in analysis, design and development.
2. ROI math: comparing apples to apples
Once an idea passes the first filter it has to be compared with the others. The problem is that different kinds of work do not speak the same language. Roughly three categories:
- Compliance / mandatory: not doing it creates a fine, an outage or a risk.
- Revenue: it brings money in.
- Cost down: it stops money going out.
Compliance and cost-down work land directly on profit. With revenue, not every unit of income is profit. For the comparison to be honest, everything has to be moved onto the profit axis.
If your gross margin is 20%, saving 100 is equivalent to earning 500 in revenue (100 ÷ 0.20 = 500). So when comparing cost-down and compliance work against revenue work, you have to multiply by 5.
Work this multiplier out once and put it somewhere everybody can see. A surprising number of prioritisation arguments are really arguments about a multiplier nobody ever stated.
3. Effort: T-shirt sizing
Trying to estimate in hours at this stage is a waste of time; there is no technical analysis yet. A rough size is enough. What matters is that the scale is exponential, not linear: as work grows, what grows with it is not just duration but uncertainty.
| Size | Roughly | Points |
|---|---|---|
| XS | 1 sprint | 1 |
| S | 2 sprints | 2 |
| M | 4 sprints | 4 |
| L | 8 sprints | 8 |
| XL | 16 sprints | 16 |
| 2XL | 32 sprints | 32 |
My own rule: nothing L or larger enters the backlog as-is. An XL item is not a piece of work, it is a wish. If it cannot be split, that is a sign it is not yet understood — and work that is not understood cannot be estimated.
4. ROI and time to market
You now have a normalised impact and a scored effort. The equation is simple:
ROI = Impact (on the profit axis) / Effort (T-shirt points)Here is the key strategy: when two items have similar ROI, always take the smaller one. Not just for speed. The smaller item ships earlier, starts returning earlier, and — most importantly — teaches you the real risk, what customers actually do, sooner.
The big item's ROI is an estimate; the small item's outcome is data you will hold in two weeks. When choosing between an estimate and data, take the data.
5. If the process slows you down, it is not Agile any more
Some teams turn prioritisation itself into bureaucracy: forms for every idea, approval layers, scoring committees. What comes out at the end is not better decisions but slower ones.
The over-engineering trap is recognisable: you are doing everything by the book and delivering no value to the customer. At that point you are not running a process, you are running process theatre.
- Test every idea with rough math the moment it appears
- Compute the margin multiplier once, keep it visible
- When ROI is close, pick the smaller item
- Do not delete rejected ideas — store them as "rejected + reason"
- Fill the filtering session with the whole team
- Ask for hour-level estimates before technical analysis
- Compare revenue and savings as if they were the same number
- End the session without dropping a single item
Checklist
- Was at least one item dropped in this session?
- Does every remaining item have a rough impact number and a T-shirt size?
- Are the impact numbers on the same axis (profit), or are you comparing apples to oranges?
- Were L and larger items split, or left as they were?
- Was the reason recorded for each rejected item? (The same idea will come back in three months.)
- Is it clear which items go into the next grooming?
Conclusion
Refinement does not end the chaos; it keeps the chaos outside the funnel. If the rough math on a piece of work does not hold, every hour spent on it is waste — and that waste surfaces in the most expensive place, in development.
The next part looks at how the surviving items reach the team. Choosing the right work is not enough; the team has to know why it is doing it.
The funnel framing, the back-of-the-envelope filter, the T-shirt scale and the ROI multiplier are adapted from İbrahim Demir's Backlog Refinement post. The L/XL rule and keeping rejected items with their reason are my additions. Melissa Perri's Escaping the Build Trap is a good follow-up read.