Die Technical Debt Priorisierungsmatrix

Technical debt backlogs sterben meist auf eine von zwei Arten: Entweder wird jeder Eintrag von dem Entwickler als „kritisch" eingestuft, der ihn am meisten nervt, oder die Liste wird komplett ignoriert, weil niemand „dieses Modul hat keine Testabdeckung" in etwas übersetzen kann, das ein Product Manager oder CFO finanzieren würde. Dieser prompt erzwingt eine Bewertung nach Geschäftsauswirkungen, bevor überhaupt eine Priorisierung der Maßnahmen stattfindet – der resultierende Plan übersteht dadurch auch eine Roadmap-Diskussion, an der Nicht-Techniker teilnehmen.

Warum jeder Abschnitt des prompts existiert

Rolle: Der prompt weist der AI die Perspektive einer Führungskraft im Engineering zu, die in ein und demselben Meeting eine Remediation-Roadmap gegenüber einem CFO und einem VP of Product vertreten muss – und nicht nur die eines erfahrenen Entwicklers, der Codequalität beurteilt. Diese Rahmung ist entscheidend, denn ein rein technischer Prüfer ordnet Einträge nach Eleganz und Korrektheit; eine Führungskraft, die sowohl für das Budget als auch für die Lieferung verantwortlich ist, ordnet sie danach, was das Geschäft tatsächlich gefährdet.

Kontext: Der prompt fragt nach der aktuellen sprint-Kapazität des Teams und den aktuellen Geschäftsprioritäten (Wachstum, Stabilität, Kostensenkung), weil ein und derselbe technical debt-Eintrag je nach aktuellem Optimierungsziel der Organisation unterschiedlich eingestuft wird. Ein wachsendes Startup und ein Unternehmen in einem Stabilitätsquartal sollten aus derselben debt-Liste keine identische Priorisierung erhalten.

Aufgabe: Jeder technical debt-Eintrag wird anhand von vier Dimensionen bewertet – Delivery Drag (wie stark er zukünftige Feature-Arbeit verlangsamt), Incident-Risiko (wie häufig er in Produktionsproblemen auftaucht), Umsatz- und Kundenexposition sowie Behebungskosten – anstatt mit einer einzigen vagen „Schweregrad"-Bewertung, weil ein einzelner Wert unterschiedliche Abwägungen in einer Zahl verschwinden lässt, gegen die niemand argumentieren kann.

Einschränkungen: Der prompt schließt „einfach alles refactorn" als Ergebnis explizit aus und verlangt, dass der Plan die angegebene sprint-Kapazität respektiert – denn eine Priorisierungsübung, die mehr Arbeit empfiehlt, als das Team bewältigen kann, ist kein Plan, sondern ein Wunschzettel.

Ausgabeformat: Die Ausgabe ist eine priorisierte Tabelle (kein Fließtext), damit sie ohne zusätzliche Formatierungsarbeit direkt in eine Roadmap-Review-Präsentation eingefügt werden kann – gefolgt von einer kurzen Begründung in verständlichem Deutsch für die drei wichtigsten Einträge, die ein nicht-technischer Stakeholder tatsächlich lesen und genehmigen kann.

Der prompt

Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting.

CONTEXT:
- Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"]
- Current business priority: [GROWTH / STABILITY / COST-CUTTING]
- Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal]

TASK:
For each debt item, score it 1-5 on each of these four dimensions:
1. Delivery drag — how much does this slow down future feature work in the affected area?
2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes?
3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly?
4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)?

Then compute a priority score and rank all items.

CONSTRAINTS:
- Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits.
- Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing.
- Justify the top 3 items in plain English a non-engineer could read and approve without a glossary.

OUTPUT FORMAT:
1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score
2. Recommended Sequence: which items fit in the stated capacity, in order
3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholder

Wie die Ausgabe tatsächlich aussieht

Für ein Team mit der Kapazität „1 Entwickler, 20% Zeit" in einem WACHSTUMS-Quartal und einer rohen Liste mit Einträgen wie „keine Testabdeckung beim Checkout-Service", „Auth-Token laufen nicht ab", „das Reporting-Dashboard fragt die primäre Datenbank direkt ab" und „unser Deploy-Skript hat drei manuelle Schritte, die jemand immer vergisst", würde eine typische Ausgabe folgendermaßen aussehen:

Umsetzbare Erkenntnisse

• Führen Sie die Analyse vor Ihrem nächsten Planungszyklus durch, nicht währenddessen – das Scoring-Gespräch bringt Meinungsverschiedenheiten über Geschäftsprioritäten ans Licht, die besser geklärt werden sollten, bevor Kapazitäten vergeben werden, und nicht mitten in einem hitzigen Roadmap-Meeting.
• Verwenden Sie die verständlichen Begründungen wörtlich, wenn Sie um Budget oder Personal bitten – sie sind gezielt dafür konzipiert, vor einem nicht-technischen Publikum zu bestehen, ohne dass Sie ad hoc übersetzen müssen.
• Führen Sie den prompt erneut aus, wann immer sich Ihre angegebene Geschäftspriorität ändert (etwa von Wachstum zu Stabilität) – dieselbe technical debt-Liste sollte eine spürbar andere Priorisierung ergeben; tut sie das nicht, müssen die Scoring-Eingaben überdacht werden.
• Überspringen Sie den expliziten Deprioritisierungsschritt nicht – eine technical debt-Liste, in der alles „wichtig" ist, ist der mit Abstand häufigste Grund dafür, dass Remediation-Roadmaps im echten sprint-Betrieb keine Chance haben.