Softwareentwicklung · Automatisierte Bug-Triage

Unklare Bug-Triage verzögert Releases und überlastet Teams

Ein Softwareunternehmen mit 3.000 Mitarbeitenden entwickelt jährlich 900 Features. Monatlich entstehen 4.500 Bugtickets, deren manuelle Triage Tage dauert.

Technologiebranche
Softwareentwicklung

Ausgangsproblem

Bug-Triage blockiert Entwicklungsteams

Lösungstyp

Agentischer Workflow für Bug-Triage

Komplexität

Transformation

Leitkennzahl

Zeitersparnis in der Bug-Triage

Nutzergruppe

Entwicklungsteams und Produktverantwortliche

Umsetzungsdauer

3-6 Monate

Betriebsmodell

Integration in Issue-Tracker und Repos

Ausgangslage

Ein Softwareunternehmen aus der Technologiebranche entwickelt mit rund 3.000 Mitarbeitenden jährlich etwa 900 neue Features für mehrere Produktlinien. Die Entwicklungsteams arbeiten in rund 20 crossfunktionalen Squads, die sich ein zentrales Issue-Tracking-System teilen. Monatlich werden im Schnitt 4.500 neue Bugtickets erfasst, davon rund 3.600 aus Kundenmeldungen und 900 aus internen Tests. Die Erstaufnahme erfolgt durch Support und QA, die Zuordnung zu Teams und Komponenten übernehmen wechselnde Duty-Rollen in der Entwicklung. Pro Arbeitstag fallen so etwa 250 neue Bugs an, die in mehreren Triage-Runden gesichtet, bewertet und verteilt werden.

4.500: Bugtickets pro Monat
20: Entwicklungsteams

Die Herausforderung

Die manuelle Bug-Triage kostet die Entwicklungsteams viel Zeit und führt zu inkonsistenten Entscheidungen. Pro Woche verbringen Senior-Entwicklerinnen und -Entwickler zusammen rund 80 Stunden damit, Tickets zu lesen, zu bewerten und an die richtigen Teams zu verteilen. Viele Bugs enthalten unstrukturierte Beschreibungen, Screenshots oder Logauszüge, die erst interpretiert werden müssen. Doppelte Meldungen werden häufig zu spät erkannt, wodurch mehrere Teams parallel an ähnlichen Problemen arbeiten. Kritische Bugs bleiben im Rauschen liegen, während laute, aber weniger dringende Tickets bevorzugt behandelt werden. Die Releaseplanung leidet unter unsicheren Zahlen zu offenen kritischen Fehlern.

„Wir verlieren jeden Montagvormittag in Triage-Meetings und kommen kaum zum Entwickeln“

„Wir wissen oft erst kurz vor dem Release, wie viele kritische Bugs wirklich offen sind“

„Viele Tickets landen im falschen Team und wandern tagelang zwischen Boards“

„Wir haben ständig Diskussionen, ob ein Bug wirklich kritisch ist oder warten kann“

Warum das bisher ungelöst blieb

Das Problem war lange bekannt, wurde aber als unvermeidlicher Teil des Entwicklungsalltags betrachtet. Frühere Verbesserungsversuche konzentrierten sich auf strengere Ticketvorlagen und zusätzliche Pflichtfelder, was jedoch die Melder belastete und die Qualität der Beschreibungen kaum verbesserte. Eine rein regelbasierte Automatisierung scheiterte daran, dass Bugs sehr unterschiedlich beschrieben werden und wichtige Hinweise in Freitext, Logs oder Anhängen stehen. Ein größeres IT-Projekt nur für die Triage schien schwer zu rechtfertigen, obwohl die Summe der Zeitverluste deutlich spürbar war.

Ticketvorlagen

Einheitliche Ticketvorlagen mit Pflichtfeldern sollten die Triage erleichtern, führten aber zu mehr Workarounds und Freitext.

Regelbasierte Zuweisung

Einfache Routing-Regeln nach Komponentenfeldern wurden eingeführt, deckten aber nur einen kleinen Teil der Tickets ab.

Eingeführt wurde ein agentischer Workflow, der die Bug-Triage entlang des bestehenden Issue-Trackers strukturiert. Neue Tickets werden automatisch analysiert, mit ähnlichen Fällen abgeglichen und mit Vorschlägen für Priorität, betroffene Komponenten und zuständige Teams angereichert. Der Workflow kombiniert Informationen aus Tickettext, Anhängen, Logs und Versionsdaten aus den Repositories. Für jedes Ticket erstellt das System einen strukturierten Triage-Steckbrief mit Kurzbeschreibung, vermuteter Auswirkung, betroffenen Services und möglichen Duplikaten. Duty-Rollen in der Entwicklung prüfen diese Vorschläge in einer fokussierten Oberfläche, bestätigen oder korrigieren sie und geben das Ticket mit einem Klick in die Backlogs der Teams frei. Rückmeldungen fließen in den Workflow ein und verbessern die Vorschläge schrittweise.

Wo generative KI arbeitet

Generative KI analysiert Freitextbeschreibungen, Logauszüge und Screenshots, fasst sie zu einer prägnanten Problembeschreibung zusammen und leitet Vorschläge für Priorität, betroffene Komponenten und zuständige Teams ab. Sie erkennt Duplikate über semantische Ähnlichkeit und liefert verwertbare Vorschläge, die Duty-Rollen nur noch prüfen und anpassen.

Bausteine

Automatische Analyse neuer Bugtickets mit Extraktion von Kontext, betroffenen Funktionen und vermuteter Auswirkung aus Freitext und Anhängen.
Semantische Duplikaterkennung, die ähnliche Bugs über Titel, Beschreibungen, Logs und Historie hinweg bündelt und zusammenführt.
Vorschlagslogik für Priorität und Routing, die Komponenten, Services und Teams anhand von Codehistorie, Ownership und bisherigen Tickets ableitet.
Triage-Steckbriefe in einer fokussierten Oberfläche, in der Duty-Rollen Vorschläge prüfen, korrigieren und mit einem Klick freigeben.
Feedbackschleifen, die bestätigte und korrigierte Vorschläge nutzen, um künftige Triage-Entscheidungen schrittweise zu verbessern.

Ist-Analyse
Erhebung von Ticketvolumen, Triage-Prozessen und beteiligten Rollen, Auswahl von Pilotteams und Definition der wichtigsten Prioritätskategorien.
Datenanbindung
Anbindung des Issue-Trackers, Auslesen historischer Tickets, Verknüpfung mit Repositories und Ownership-Daten, Definition der Routingziele.
Modellierung
Konfiguration der agentischen Logik für Analyse, Duplikaterkennung und Routing, Training auf historischen Triage-Entscheidungen der Pilotteams.
Pilotbetrieb
Einführung des Triage-Assistenten in zwei Pilotteams, parallele Nutzung mit manueller Triage, Vergleich der Entscheidungen und Feinjustierung.
Rollout
Schrittweiser Rollout auf alle Entwicklungsteams, Anpassung der Duty-Rollen, Schulungen und Monitoring der Effekte auf Durchlaufzeiten und Qualität.

Kennzahl	Wert	Basis
Zeitaufwand für Bug-TriageLeitkennzahl	Reduktion um rund 55 Prozent	Zeiterfassung vor/nachgemessen
Durchlaufzeit bis zur Teamzuordnung	von 2 Tagen auf 6 Stunden	Systemmessunggemessen
Korrekturen der automatischen VorschlägeGütemaß	rund 18 Prozent der Tickets	Stichprobegeschätzt

Aufwandsklasse

Standard (60-150 PT)

Amortisation

6-12 Monate

Haupthebel

Zeitersparnis

Laufende Kosten

Betrieb des Workflows als Erweiterung des Issue-Trackers mit nutzungsabhängigen KI-Kosten und geringem Administrationsaufwand.

Einschränkung

Die Lösung entfaltet ihren vollen Nutzen vor allem bei stabilen Ownership-Strukturen und gepflegten Komponentenfeldern. In Phasen großer organisatorischer Umbrüche oder stark wechselnder Teams steigt der Bedarf an manueller Kontrolle.

Angebundene Systeme

Anbindung an das zentrale Issue-Tracking-System, Leserechte auf Repositories für Metadaten, Nutzung eines internen Ownership-Verzeichnisses für Teamzuordnungen.

Betrieb

Betrieb in einer isolierten Umgebung innerhalb der bestehenden Cloud-Infrastruktur des Unternehmens, mit getrennten Projektmandanten und rollenbasiertem Zugriff.

Compliance

Bugdaten bleiben im Unternehmensnetz, personenbezogene Informationen werden minimiert, Zugriffe werden protokolliert und Triage-Entscheidungen revisionssicher im Issue-Tracker nachgehalten.

Kennzeichnung

Im Issue-Tracker werden automatisch generierte Vorschläge klar als solche markiert, inklusive Hinweis auf erforderliche menschliche Bestätigung.

Verbindlichkeit

Vorschläge des Systems sind nicht bindend, Freigaben und Prioritätsentscheidungen liegen weiterhin bei den verantwortlichen Personen in den Entwicklungsteams.

Eskalationspfad

Unklare oder widersprüchliche Tickets können direkt aus der Triage-Oberfläche an spezialisierte Teams oder Produktverantwortliche eskaliert werden.

Nachvollziehbarkeit

Für jedes Ticket werden die herangezogenen Signale, Vorschläge und Bestätigungen protokolliert, sodass spätere Analysen von Fehlpriorisierungen möglich sind.

Rollen im Betrieb

Produktverantwortliche und Duty-Rollen in der Entwicklung nutzen den Assistenten täglich, das Plattformteam betreut Integration und Monitoring, die QA liefert Feedback zu Priorisierung und Duplikaten.

Übertragbarkeit

Der agentische Workflow für Bug-Triage lässt sich auf andere Kontexte übertragen, in denen viele unstrukturierte Meldungen bewertet, priorisiert und an Teams verteilt werden müssen. Entscheidend ist, dass es ein zentrales System für Vorgänge gibt und historische Entscheidungen als Lernbasis dienen. Branchen mit komplexen Produkten, vielen Varianten und hoher Änderungsfrequenz profitieren besonders, wenn bisher erfahrene Fachkräfte viel Zeit mit dem Sortieren und Zuordnen von Tickets oder Meldungen verbringen.