Two hundred items in the backlog, the oldest a year and a half old. Nobody remembers who raised it or whether the problem it describes still exists. Every week more tickets arrive than the team closes, and every conversation about priorities ends the same way: everything is important, so nothing is. If you run a company or own a product, a list like that is not a technical problem. It is a decision problem. And it can be solved without hiring three more developers.
Before you speed anything up, delegate or cut, the backlog needs sorting. Not by submission date, and not by who shouts loudest for their items.
Step 1: split the tickets into four buckets
The first sort is done by business impact, not technical difficulty:
- Revenue-critical: tickets that block sales, customer service or invoicing. Every day of delay has a countable cost.
- Compliance with a hard deadline: KSeF, GDPR, the EU AI Act. The cut-off date does not negotiate, and the penalty can be higher than the cost of the entire change.
- Quality-of-life: they block nothing directly but cost people time every day. Manual rekeying of data, a report stitched together in a spreadsheet, workarounds everyone has grown used to.
- Nice-to-have: ideas that seemed good a year ago and that nobody has asked about since.
Our projects keep confirming a simple observation: the last bucket is often 30–50% of the whole list. Delete it without hesitation. If an idea is genuinely needed, it will come back on its own, with a better justification than the first time round.
Step 2: add the second axis, who should do the work
For the tickets that survived the first cut, ask a second question: does delivery require deep knowledge of your domain, or is it standard engineering work? Adding a field to a form, an API integration, a new report, a data migration, regression tests: all of that looks the same in a haulage company and in a pharmaceutical wholesaler. Pricing logic, a route-planning algorithm, customer scoring rules: nobody who does not know your business will do those well.
These two axes produce a matrix that puts the decisions in order:
- Urgent and standard: the best candidate for delegating to an external partner. Well-defined inputs and outputs, little tribal context.
- Urgent and domain-specific: your own team, straight away. There is no shortcut here.
- Not urgent and standard: delegate in batches, once a sensible package builds up.
- Not urgent and domain-specific: consciously parked, with a specific review date instead of an eternal "someday".
A common mistake: delegating the wrong way round
And here one opinion, formed on modernisation projects: many companies split the work exactly backwards. They hand the hard, domain-specific tasks to outsiders because "we don't have the people for this", and keep the simple changes in-house because they look cheap. The result is doubly bad. The external partner spends years learning a domain the company should control itself, because that domain is its competitive edge. Meanwhile the in-house senior burns weeks adding fields to forms, work any solid contractor would do. Keep the domain core in-house even when it goes slower. Hand over the standard work without sentiment.
How to tell the backlog is getting healthier
The number of items on the list says little. Two metrics say almost everything:
- The age of the oldest active ticket. If it drops from 18 months to 3, the queue is genuinely moving. If it grows, the sorting was cosmetic.
- Lead time, the median from ticket raised to a working change in production. It is the only measure the business actually feels.
Plus one control check: the monthly balance of inflow versus delivery. As long as more arrives than gets done, no prioritisation will be enough — you need to increase throughput or cut more boldly. One caveat: these metrics are easy to game. Deleting old tickets just to improve the chart tidies the report, not the company.
Where ESKOM AI fits in this setup
In this division of labour we take the right-hand column of the matrix: we pick up standard changes, integrations between systems and regression test automation, while your team stays the owner of the domain core. A process built on a team of specialised AI agents, with a full range of automated tests (unit, integration, E2E, UI, security and performance), lets us close a typical "standard work" ticket in days or weeks; we wrote about where that speed comes from in how AI shortens change delivery time. To be fair: the first weeks of a collaboration are slower, because we need to learn your system and environment. That entry cost pays back from the following tickets onwards, so for a single minor fix this model makes no sense. For a stream of changes it makes a great deal of sense.
What to do this Friday
Block an hour in your calendar and go through the list with a spreadsheet open: four buckets, then the second axis. After that hour you will know three things: what to delete, what to do with your own people and what can be handed out externally right away. And if you want to walk through this split with someone who has done it many times, book a free consultation via the form at eskom.ai/pl/kontakt. Come with a backlog export. You will leave with a sorted list and realistic time ranges for the tickets that are fit to delegate immediately.