Tweehonderd items in de backlog, het oudste van anderhalf jaar geleden. Niemand weet nog wie het heeft gemeld of dat het probleem waarover het gaat überhaupt nog bestaat. Elke week komen er meer tickets bij dan het team afsluit, en elk gesprek over prioriteiten eindigt hetzelfde: alles is belangrijk, dus niets is dat. Als je een bedrijf leidt of verantwoordelijk bent voor een product, is zo'n lijst geen technisch probleem. Het is een beslissingsprobleem. En het is op te lossen zonder drie extra programmeurs aan te nemen.
Voordat je iets gaat versnellen, uitbesteden of schrappen, moet de backlog gesorteerd worden. Niet op meldingsdatum, en niet op wie het hardst om aandacht roept.
Stap 1: verdeel de tickets over vier bakken
De eerste sortering gebeurt op zakelijke gevolgen, niet op technische moeilijkheid:
- Kritiek voor de omzet: tickets die de verkoop, de klantenservice of de facturatie blokkeren. Elke dag uitstel heeft een becijferbare prijs.
- Compliance met een harde deadline: KSeF, de AVG, de AI-verordening (EU AI Act). Over de einddatum valt niet te onderhandelen, en de boete is soms hoger dan de kosten van de hele aanpassing.
- Quality-of-life: ze blokkeren niets direct, maar kosten mensen elke dag tijd. Handmatig gegevens overtypen, een rapport dat in een spreadsheet in elkaar wordt geknutseld, workarounds waaraan iedereen gewend is geraakt.
- Nice-to-have: ideeën die een jaar geleden goed leken en waarnaar sindsdien niemand meer heeft gevraagd.
Uit onze projecten komt een simpele observatie: die laatste bak beslaat vaak 30–50% van de hele lijst. Gooi hem gerust weg. Is een idee echt nodig, dan komt het vanzelf terug, en met een betere onderbouwing dan de eerste keer.
Stap 2: voeg een tweede as toe, namelijk wie dit hoort te doen
Stel voor de tickets die de eerste schifting hebben overleefd een tweede vraag: vergt de uitvoering diepe kennis van jouw domein, of is het standaard engineeringwerk? Een veld toevoegen aan een formulier, een integratie via een API, een nieuw rapport, een datamigratie, regressietests: dat ziet er allemaal hetzelfde uit bij een transportbedrijf en bij een farmaceutische groothandel. Prijslogica, een algoritme voor routeplanning, regels voor klantscoring: dat doet niemand goed die jouw business niet kent.
Uit die twee assen ontstaat een matrix die de beslissingen ordent:
- Urgent en standaard: de beste kandidaat om aan een externe partner uit te besteden. Goed gedefinieerde input en output, weinig stamkennis nodig.
- Urgent en domeinspecifiek: het eigen team, meteen. Hier bestaat geen sluiproute.
- Niet urgent en standaard: in batches uitbesteden zodra er een zinvol pakket ligt.
- Niet urgent en domeinspecifiek: bewust uitgesteld, met een concrete reviewdatum in plaats van een eeuwig ‘ooit’.
Een veelgemaakte fout: omgekeerd delegeren
En hier één mening, gevormd op moderniseringsprojecten: veel bedrijven verdelen het werk precies andersom. Moeilijke, domeinspecifieke taken geven ze uit handen omdat ‘we daar de mensen niet voor hebben’, en simpele aanpassingen houden ze zelf omdat die goedkoop lijken. Het resultaat is dubbel slecht. De externe partner leert jarenlang een domein kennen dat het bedrijf zelf zou moeten beheersen, want daar zit zijn concurrentievoordeel. En de eigen senior verstookt weken aan het toevoegen van velden aan formulieren, werk dat elke degelijke uitvoerder zou kunnen doen. Houd de domeinkern in eigen huis, ook als het dan langzamer gaat. Besteed het standaardwerk zonder sentiment uit.
Waaraan zie je dat de backlog gezonder wordt
Het aantal items op de lijst zegt weinig. Twee metrieken zeggen bijna alles:
- De leeftijd van het oudste actieve ticket. Zakt die van 18 maanden naar 3, dan komt er echt beweging in de wachtrij. Stijgt hij, dan was het sorteren cosmetisch.
- Lead time, oftewel de mediane tijd van melding tot werkende wijziging in productie. Dit is de enige maat die de business voelt.
Daarbij één controletest: de balans tussen instroom en afhandeling per maand. Zolang er meer bijkomt dan verdwijnt, is geen enkele prioritering genoeg — dan moet de capaciteit omhoog of het mes er dieper in. Eén kanttekening: deze metrieken zijn makkelijk te foppen. Oude tickets wissen alleen om de grafiek op te poetsen, ruimt het rapport op, niet het bedrijf.
Waar ESKOM AI in dit geheel staat
In deze werkverdeling nemen wij de rechterkolom van de matrix voor onze rekening: we nemen standaardaanpassingen, integraties tussen systemen en de automatisering van regressietests over, terwijl jouw team eigenaar blijft van de domeinkern. Een proces gebaseerd op een team gespecialiseerde AI-agents, met een volledig pakket geautomatiseerde tests (unit-, integratie-, E2E-, interface-, security- en performancetests), maakt het mogelijk een typisch ticket uit de bak ‘standaardwerk’ in dagen of weken af te ronden; waar die snelheid vandaan komt, beschreven we in het artikel hoe AI de doorlooptijd van wijzigingen verkort. Eerlijk is eerlijk: de eerste weken van de samenwerking gaan trager, omdat we jouw systeem en omgeving moeten leren kennen. Die instapkosten verdienen zich vanaf de volgende tickets terug, dus voor één losse kleine aanpassing heeft dit model geen zin. Voor een stroom wijzigingen des te meer.
Waar je deze vrijdag mee begint
Blokkeer een uur in je agenda en loop de lijst door met een spreadsheet ernaast: vier bakken, daarna de tweede as. Na dat uur weet je drie dingen: wat je schrapt, wat je met eigen mensen doet en wat je per direct kunt uitbesteden. En wil je deze indeling doorlopen met iemand die dit al vele malen heeft gedaan, plan dan een gratis consult via het formulier op eskom.ai/pl/kontakt. Neem een export van je backlog mee. Je vertrekt met een gesorteerde lijst en een reële tijdsindicatie voor de tickets die zich direct voor uitbesteding lenen.