To hundrede punkter i backloggen, det ældste halvandet år gammelt. Ingen husker længere, hvem der meldte det ind, eller om problemet overhovedet stadig findes. Hver uge kommer der flere sager til, end teamet lukker, og enhver samtale om prioriteter ender ens: alt er vigtigt, så intet er det. Driver du en virksomhed eller har du ansvaret for et produkt, er sådan en liste ikke et teknisk problem. Det er et beslutningsproblem. Og det kan løses uden at ansætte tre ekstra udviklere.
Før du begynder at fremskynde, uddelegere eller skære noget væk, skal backloggen sorteres. Ikke efter indmeldelsesdato og ikke efter, hvem der råber højest om sit.
Trin 1: fordel sagerne i fire kurve
Den første sortering laves efter forretningsmæssige konsekvenser, ikke efter teknisk sværhedsgrad:
- Kritisk for omsætningen: sager, der blokerer salg, kundeservice eller fakturering. Hver dags forsinkelse har en omkostning, der kan gøres op.
- Compliance med hård deadline: KSeF, GDPR, AI-forordningen (EU AI Act). Skæringsdatoen forhandler ikke, og bøden kan være højere end prisen for hele ændringen.
- Quality-of-life: blokerer ikke noget direkte, men koster folk tid hver dag. Manuel indtastning af data, rapporten, der klistres sammen i et regneark, workarounds, som alle har vænnet sig til.
- Nice-to-have: idéer, der virkede gode for et år siden, og som ingen har spurgt til siden.
Fra vores projekter kommer en enkel observation: den sidste kurv udgør ofte 30–50% af hele listen. Slet den uden tøven. Er en idé virkelig nødvendig, vender den tilbage af sig selv, og med en bedre begrundelse end første gang.
Trin 2: tilføj den anden akse — hvem bør udføre det
For de sager, der overlevede den første nedskæring, stiller du det næste spørgsmål: kræver opgaven dyb viden om dit domæne, eller er den standard ingeniørarbejde? Et nyt felt i en formular, en integration via API, en ny rapport, datamigrering, regressionstests: alt det ser ens ud i en transportvirksomhed og i en medicinalgrossist. Prislogikken, ruteplanlægningsalgoritmen, reglerne for kundescoring: det laver ingen godt, som ikke kender din forretning.
Af de to akser opstår en matrix, der bringer orden i beslutningerne:
- Hastende og standard: den bedste kandidat til at uddelegere til en ekstern partner. Veldefineret input og output, lidt stammeviden.
- Hastende og domænespecifik: eget team, med det samme. Her findes ingen genvej.
- Ikke hastende og standard: uddelegér i bundter, når der har samlet sig en fornuftig pakke.
- Ikke hastende og domænespecifik: bevidst udskudt, med en konkret dato for genbesøg i stedet for et evigt "engang".
En hyppig fejl: delegering på hovedet
Og her en holdning, formet af moderniseringsprojekter: mange virksomheder fordeler arbejdet stik modsat. De svære, domænespecifikke opgaver sendes ud af huset, fordi "vi ikke har folk til det", mens de simple ændringer holdes hjemme, fordi de virker billige. Resultatet er dobbelt skidt. Den eksterne partner bruger år på at lære et domæne, virksomheden selv burde kontrollere, fordi det er dens konkurrencefordel. Og ens egen senior brænder uger af på at tilføje felter til formularer, altså arbejde, enhver solid leverandør kunne udføre. Behold domænekernen in-house, også når det går langsommere. Aflever standardarbejdet uden sentimentalitet.
Sådan ser du, at backloggen bliver sundere
Antallet af punkter på listen siger ikke meget. To målepunkter siger næsten alt:
- Alderen på den ældste aktive sag. Falder den fra 18 måneder til 3, kører køen reelt rundt. Stiger den, var sorteringen kosmetisk.
- Lead time, altså medianen af tiden fra indmeldelse til en fungerende ændring i produktion. Det er det eneste mål, forretningen kan mærke.
Dertil én kontroltest: balancen mellem tilgang og afgang pr. måned. Så længe der kommer flere til, end der forsvinder, er ingen prioritering nok — kapaciteten skal op, eller der skal skæres modigere. Ét forbehold: de her målepunkter er lette at snyde. Sletter man gamle sager alene for at pynte på grafen, rydder man op i rapporten, ikke i virksomheden.
Hvor ESKOM AI passer ind i det setup
I den arbejdsdeling indtager vi matrixens højre kolonne: vi overtager standardændringer, integrationer mellem systemer og automatisering af regressionstests, mens dit team forbliver ejer af domænekernen. En proces baseret på et hold specialiserede AI-agenter, med fuld automatisk testdækning (unit-, integrations-, E2E-, UI-, sikkerheds- og performancetests), gør det muligt at lukke en typisk sag fra kurven "standardarbejde" på dage eller uger; hvor den hastighed kommer fra, har vi skrevet om i artiklen hvordan AI forkorter leveringstiden på ændringer. Helt ærligt: de første ugers samarbejde går langsommere, fordi vi skal lære dit system og miljø at kende. Den indgangsomkostning tjener sig hjem fra de følgende sager, så for en enkelt lille rettelse giver modellen ikke mening. For en strøm af ændringer giver den stor mening.
Hvad du kan gøre allerede på fredag
Blokér en time i kalenderen og gå listen igennem med et regneark ved siden af: fire kurve, derefter den anden akse. Efter den time ved du tre ting: hvad der skal slettes, hvad I selv skal lave, og hvad der kan sendes ud af huset med det samme. Og vil du gennemgå opdelingen med en, der har gjort det mange gange, så book en gratis konsultation via formularen på eskom.ai/pl/kontakt. Kom med et eksport af backloggen. Du går derfra med en sorteret liste og realistiske tidsrammer for de sager, der egner sig til uddelegering med det samme.