Öffne die Statistikseite fast jedes Bug-Trackers, und du findest jede Menge Zahlen. Alle jemals erfassten Issues. Ein Tortendiagramm nach Schweregrad. Eine durchschnittliche Bearbeitungszeit. Ein Balken pro zuständiger Person.
Fast keine davon beantwortet die Frage, die ein Team am Montagmorgen tatsächlich stellt: Kommen wir hinterher, oder fallen wir zurück?
Die Antwort darauf ist kurz, und sie braucht vier Zahlen. Hier geht es um diese vier, um die beliebten Metriken, die unbemerkt in die Irre führen, und um einen fünfminütigen Wochen-Review, der auf ihnen aufbaut. Dieselben Überlegungen stecken hinter dem Pulse-Header, den ich gerade oben auf das Board von BugDump gesetzt habe.
Metriken, die nützlich aussehen und es nicht sind
Alle jemals erfassten Bugs. Die Zahl steigt nur. Eine Zahl, die nur steigen kann, sagt dir, wie alt das Projekt ist, nicht, wie gesund es ist.
Anzahl der Fehlerberichte. Berichte messen den Traffic genauso wie die Qualität. Ein einziger kaputter Checkout-Button kann an einem Nachmittag vierzig Berichte erzeugen, und das ist ein Bug, nicht vierzig. Zählst du Berichte, sieht ein beliebtes Release wie eine Katastrophe aus. Zählst du Bugs, sieht es aus wie ein ganz normaler Dienstag.
Bugs nach Schweregrad als Tortendiagramm. Es beschreibt den Backlog, ohne nahezulegen, was zu tun ist. Noch nie hat jemand auf ein Tortendiagramm geschaut und daraufhin ein Ticket geschlossen.
Durchschnittliche Zeit bis zum Fix. Diese Metrik richtet echten Schaden an, weil sie gründlich wirkt. Darauf komme ich noch zurück.
Gemeinsam ist ihnen, dass sie Bestandsgrößen sind, keine Stromgrößen. Sie beschreiben einen Stapel. Die Fragen, die sich lohnen, betreffen die Richtung, in die sich der Stapel bewegt, und das, was ganz unten feststeckt.
1. Offener Backlog und seine Richtung
Fang mit der einfachsten Zahl an, die es gibt: Wie viele Bugs sind gerade offen? In BugDump ist das jede Aufgabe, die noch nicht in einer geschlossenen Spalte gelandet ist.
Für sich allein sagt die Zahl wenig. Neunundzwanzig offene Bugs sind für ein Team in Ordnung und für ein anderes alarmierend. Entscheidend ist die Richtung, und die Richtung ist einfache Arithmetik über ein Zeitfenster:
Nettoänderung = neue Bugs − behobene Bugs, im selben Zeitraum
Negativ heißt, der Backlog schrumpft. Positiv heißt, er wächst. Null bei Aktivität heißt, du hältst genau Schritt. Null ohne Aktivität heißt, niemand hat etwas angefasst. Das ist eine andere Situation und verdient eine andere Beschriftung.
Deshalb zeigt der Pulse-Header nicht einfach „29 offen“. Er sagt Backlog in diesem Zeitraum um 4 gesunken, Backlog in diesem Zeitraum um 6 gestiegen, Backlog bleibt stabil oder ruhige Phase, nichts hat sich bewegt. Die Zahl gibt die Größenordnung, der Satz die Richtung.
Ein Backlog, der mehrere Zeiträume hintereinander wächst, ist selten ein Problem der Produktivität im Entwicklungsteam. Fast immer ist es ein Triage-Problem: Duplikate werden nicht zusammengeführt, Entscheidungen gegen einen Fix werden nicht getroffen, und jeder Bericht wird zum Dauergast.
2. Behoben vs. neu, verglichen mit dem vorherigen Zeitraum
Die zweite Zahl ist, wie viele Bugs du im Zeitfenster behoben hast, gegenübergestellt dem vorherigen Zeitfenster gleicher Länge.
Der Vergleich mit dem direkt vorangegangenen Zeitraum statt mit einem Durchschnitt über alle Zeiten ist aus zwei Gründen wichtig. Er gleicht Saisonalität aus: Zwei ruhige Urlaubswochen werden mit den zwei hektischen Wochen davor verglichen, nicht mit deinem besten Monat überhaupt. Und er macht Release-Wochen lesbar: Ein Release, das eine ganze Gruppe von Bugs behoben hat, erscheint als Sprung, nicht als Rauschen.
Noch besser: Sieh dir neue und behobene Bugs im selben Diagramm an. Ich zeichne neue Bugs über der Achse ein, behobene darunter und den Backlog als Linie über beide. Spiegeln sich die beiden Flächen, hältst du Schritt. Gewinnt die obere immer wieder, steigt die Linie, und du siehst genau, an welchen Tagen das anfing.
3. Mediane Zeit bis zum Fix, nicht der Durchschnitt
Die Zeit bis zum Fix ist die Metrik, die die meisten Teams wollen und die die meisten Tools falsch berechnen.
Die Definition ist einfach: Miss für jeden Bug, der im Zeitfenster behoben wurde, die Zeit vom Öffnen bis zur Behebung. Die Frage ist, wie du diese Dauern zusammenfasst, und die Antwort sollte fast nie der Mittelwert sein.
Ein Beispiel. Angenommen, dein Team behebt in diesen zwei Wochen zehn Bugs. Neun davon innerhalb eines Tages. Der zehnte ist ein Bug von vor vier Monaten, den jemand beim Aufräumen endlich geschlossen hat, 120 Tage nach dem Erfassen.
Mittelwert: (9 × 1 + 120) ÷ 10 = 12,9 Tage
Median: 1 Tag
Der Mittelwert sagt, dein Team braucht zwei Wochen, um einen Bug zu beheben. Der Median sagt, dein Team behebt Bugs am nächsten Tag, und er hat recht. Schlimmer noch: Der Mittelwert bestraft das Aufräumen. In der Woche, in der du endlich uralte Tickets schließt, sieht dein Durchschnitt furchtbar aus, und alle lernen daraus, uralte Tickets in Ruhe zu lassen.
Der Median ist robust gegen diesen einen Ausreißer und bildet ab, was ein typischer Bug erlebt. Ihn zeigt der Pulse-Header als Mediane Fixzeit, je nach Größenordnung in Minuten, Stunden oder Tagen.
Er hat eine ehrliche Schwäche: Er zählt nur Bugs, die tatsächlich behoben wurden. Ein Bug, der nie gelöst wird, geht nie in die Rechnung ein. Ein Team kann also einen wunderbaren Median haben und gleichzeitig still seine schwierigsten Probleme liegen lassen. Genau deshalb brauchst du die vierte Zahl.
4. Der älteste offene Bug
Der Median beschreibt die Mitte. Der älteste offene Bug beschreibt das Ende der Verteilung, und dort geht Vertrauen verloren.
Setz sein Alter direkt neben den Median: 5 Monate, darunter ID und Titel. Mach den Eintrag anklickbar, damit ein Blick darauf ein einziger Schritt ist und keine Suche.
Ein Bug, der seit fünf Monaten offen ist, ist fast nie ein Bug, den niemand beheben konnte. Er ist eine Entscheidung, die niemand getroffen hat. Wer ihn sich ansieht, landet bei einem von drei ehrlichen Ergebnissen:
Beheben, weil er sich als klein herausstellt.
Einplanen, weil er wichtig ist und verwaist war.
Bewusst schließen, als „wird nicht behoben“ oder „überholt“, und der Person, die ihn gemeldet hat, den Grund nennen.
Jedes der drei ist besser als ein vierter Monat Schweigen. Und sobald der älteste Bug erledigt ist, rückt der nächstälteste nach. So holt die Zahl das Ende der Verteilung immer weiter heran.
Bonus: Woher die Berichte kommen
Die vier Zahlen oben sagen dir, ob du hinterherkommst. Sie sagen dir nicht, warum eine Woche schlecht lief.
Dafür schlüsselst du die Berichte im selben Zeitfenster nach Browser, Betriebssystem, Gerätetyp und Seite auf. Eine Regression verteilt sich selten gleichmäßig. Wenn ein Drittel der Berichte dieser Woche von Safari auf iOS kommt oder die Seite mit den meisten Berichten ein Checkout-Schritt ist, der am Donnerstag live ging, hast du die Ursache gefunden, bevor du einen einzigen Bericht geöffnet hast.
In BugDump zeigt der aufgeklappte Pulse-Header genau diese Aufschlüsselung neben dem Diagramm, mit den Seiten mit den meisten Berichten ganz oben. Ein Klick auf einen Browser-, Betriebssystem- oder Geräte-Chip filtert das Board danach. Der Weg von „mit Safari stimmt was nicht“ zu den Safari-Bugs ist also ein Klick.
Hier ist es auch richtig, Berichte statt Bugs zu zählen. Vierzig Berichte zu einem Bug sind vierzig Datenpunkte darüber, wen er getroffen hat.
Das Zeitfenster wählen
Das Zeitfenster bestimmt, was die Zahlen dir sagen können. Wähl es passend zur Frage, die du stellst:
7 Tage für Release-Wochen, wenn du die Wirkung eines Deploys sehen willst.
14 Tage als vernünftiger Standard: lang genug, um tägliches Rauschen zu glätten, kurz genug, um zu reagieren.
30 oder 90 Tage für Trendfragen und Retrospektiven.
Vorsicht mit Medianen über kurze Zeitfenster in kleinen Projekten. Der Median aus drei Fixes ist eine Aussage über drei Bugs, nicht über dein Team.
„Behoben“ ehrlich definieren
Jede dieser Metriken hängt davon ab, was als behoben zählt, und genau hier lügen Dashboards am häufigsten.
Zählt Bereit für QA oder Gemergt als behoben, misst deine mediane Fixzeit, wie schnell Code geschrieben wird, und nicht, wie schnell niemand mehr auf den Bug stößt. Zählt Wird nicht behoben nicht mit, schleppt dein Backlog Entscheidungen mit, die längst gefallen sind.
In BugDump gilt ein Bug als behoben, sobald er in eine geschlossene Spalte kommt, und wer ihn wieder herauszieht, öffnet ihn erneut. Egal, welches Tool du nutzt: Prüf, ob seine geschlossenen Zustände das bedeuten, was die Leute, die deine Software nutzen, unter „behoben“ verstehen würden.
Der fünfminütige Wochen-Review
Mit diesen vier Zahlen auf einem Bildschirm ist ein wöchentlicher Bug-Review kein Meeting mehr, sondern eine Checkliste:
Sinkt der Backlog oder bleibt er stabil? Wenn er gewachsen ist, schau dir an, was hereinkam, nicht, wer langsam ist.
Wurden mindestens so viele Bugs behoben, wie hereinkamen, verglichen mit dem vorherigen Zeitraum?
Hat sich die mediane Fixzeit bewegt? Wenn sie gesprungen ist, such die ein oder zwei Bugs, die sie nach oben gezogen haben.
Öffne den ältesten Bug. Beheb ihn, plan ihn ein oder schließ ihn mit Begründung. Schieb ihn nicht auf nächste Woche.
Sieh nach, woher die Berichte kamen. Jeder Browser, jedes Gerät und jede Seite mit deutlich mehr als dem eigenen Anteil ist eine Regression, bis das Gegenteil bewiesen ist.
Das ist der ganze Review. Er passt in ein Standup, braucht keine Tabelle und beantwortet die einzige Frage, die das Dashboard je beantworten sollte.
Von 40 Berichten zu 6 Bugs: wie Triage funktionieren sollte – warum Berichte und Aufgaben getrennt gehören und doppelte Berichte beim Debuggen helfen.
Bugs schneller triagieren: ein Workflow für die Tastatur – wie du bei der Triage die Navigation loswirst, statt schneller denken zu müssen.
Prioritätsstufen für Bugs: warum vier feste Stufen nie passen – wofür eine Prioritätsskala da ist, wie viele Stufen du brauchst und warum die Namen von dir kommen müssen.