Jeder Issue-Tracker bekommt irgendwann benutzerdefinierte Felder, und jedes Team, das sie bekommt, durchläuft dieselben Phasen: ein Schub Begeisterung, elf neue Felder und sechs Wochen später ein Formular, in dem neun davon bei jedem Ticket leer sind.
Schuld sind nicht die benutzerdefinierten Felder. Das Problem ist, dass „wäre das nützlich zu wissen?“ die falsche Frage ist, bevor man eins anlegt. Fast alles wäre nützlich zu wissen.
Der Test, der sich lohnt
Bevor du ein Feld hinzufügst, frag: Welche Entscheidung ändert sich dadurch?
Nicht „was würde uns das sagen“, sondern was du anders machen würdest. Wenn die ehrliche Antwort „wir könnten es sehen“ lautet, ist das ein Feld, das in einem Monat leer ist, denn niemand füllt ein Kästchen aus, das nichts ändert.
Zwei Beispiele, in denen dieselbe Information den Test einmal besteht und einmal nicht:
Betroffene Version in einem Team, das wöchentlich ausliefert und zwei Releases unterstützt: besteht. Davon hängt ab, ob ein Bug einen Backport braucht.
Betroffene Version in einer Web-App mit Continuous Deployment: fällt durch. Alle sind auf derselben Version. Das Kästchen speichert nur das Datum in einem schlechteren Format.
Das Feld ist identisch. Die Entscheidung nicht.
Der zweite Test: Wer füllt es aus?
Realistisch ist ein Feld, das ausfüllt, wer gerade triagiert. Ein Feld, das Informationen braucht, die nur die meldende Person hat oder die erst nach einer Untersuchung im Entwicklungsteam vorliegen, wird bei der Triage übersprungen und nie wieder angefasst.
Wenn sich ein Feld erst spät beantworten lässt, ist es kein Triage-Feld. Steht es neben der Priorität, bremst es jeden Triage-Durchgang und bleibt trotzdem leer.
Felder, die sich zuverlässig auszahlen
Kundenstufe (Auswahl). Wenn die Dringlichkeit eines Bugs wirklich davon abhängt, wen er getroffen hat, ist das das eine Feld, das die Reihenfolge der Triage am stärksten verändert. Es besteht den Entscheidungstest glatt.
Regression? (Checkbox). Ein Bit, bei der Triage ausgefüllt, und es teilt den Backlog in „das haben wir kaputtgemacht“ und „das war nie richtig“. Das sind zwei verschiedene Warteschlangen mit zwei verschiedenen Dringlichkeiten.
Verknüpfter PR (URL). Nicht zum Tracking, sondern für die Person, die den Bug in vier Monaten wieder öffnet und wissen will, was schon versucht wurde.
Review oder QA-Verantwortung (Mitglied). Nur wenn wirklich eine zweite Person abnehmen muss. Wenn „Zuständig“ die einzige Rolle in deinem Team ist, ist das ein Feld, das immer mit der zuständigen Person übereinstimmt.
Felder, auf die du verzichten solltest
Alles, was sich ableiten lässt. Tage offen, Anzahl der Berichte, hat Anhänge: Der Tracker weiß das schon, und eine von Hand gepflegte Kopie veraltet, sobald es zum ersten Mal jemand vergisst.
Ein zweiter Status. Blockiert, Infos fehlen, Wartet auf Kundschaft als Feld neben der Board-Spalte heißt, dass der echte Zustand der Aufgabe an zwei Orten lebt, die sich irgendwann widersprechen. Wenn es ein Zustand ist, ist es eine Spalte. Und wenn du dafür keine Spalte willst, willst du den Zustand wahrscheinlich auch nicht.
Freitext, wo eine Auswahl hingehört. Ein Textfeld namens Komponente sammelt checkout, Checkout, check-out und chkout, und danach lässt es sich weder filtern noch zählen. Wenn du danach gruppieren willst, muss es eine feste Liste sein.
Alles, was du hinzufügst, weil eine Person einmal danach gefragt hat. Felder sind billig anzulegen und sozial teuer zu entfernen. Die Latte sollte höher liegen als „jemand hat es mal erwähnt“.
Den richtigen Typ wählen
Typen sind keine Dekoration. Sie entscheiden, was du das Board später fragen kannst.
Typ | Nimm ihn, wenn | Damit kannst du |
|---|---|---|
Auswahl | es eine feste Menge an Optionen gibt | sauber filtern und gruppieren |
Mehrfachauswahl | mehrere aus einer festen Menge zutreffen | fragen „betrifft iOS oder Android“ |
Zahl | es eine echte Menge ist | nach einem Bereich filtern |
Datum | es ein Zeitpunkt ist | nach einem Bereich filtern |
Checkbox | ein Bit reicht | das Board in zwei Hälften teilen |
Text / URL | alles andere | nur nach Teilstrings suchen |
Der häufigste Fehler ist, zu Text zu greifen, weil er am schnellsten eingerichtet ist. Text ist der Typ, den du wählst, wenn du akzeptiert hast, dass du nie nach diesem Feld filtern wirst.
In BugDump lässt sich der Typ einer Eigenschaft nach dem Anlegen nicht mehr ändern, weil die schon gespeicherten Werte die Form dieses Typs haben. Die dreißig Sekunden für die Wahl lohnen sich also.
Weniger Felder, dafür ausgefüllt
Was ein Board nützlich macht, ist nicht, wie viel es erfassen kann. Sondern dass man dem, was es erfasst, vertrauen kann.
Drei Felder, die bei jeder Aufgabe gesetzt sind, schlagen elf, von denen jedes bei einem Drittel gesetzt ist. Ein dünn besetztes Feld ist schlimmer als gar keins: Es sieht aus wie Daten, also filtern Leute danach, und der Filter schließt still jede Aufgabe aus, bei der jemand in Eile war.
Eine praktische Gewohnheit: Schau nach einem Monat, wie oft jedes benutzerdefinierte Feld gesetzt ist. Alles unter etwa der Hälfte ist entweder schlecht benannt, schlecht platziert oder beantwortet eine Frage, die niemand hat. Lösch es. In BugDump entfernt das Löschen einer Eigenschaft sie und ihre Werte, lässt die Aufgaben aber unangetastet. Das Aufräumen kostet also nur die Entscheidung.
So funktioniert es in BugDump
Benutzerdefinierte Eigenschaften liegen auf der Seite Eigenschaften des Projekts, neben den fünf eingebauten: Status, zuständige Person, Priorität, Labels und Fälligkeitsdatum. Die eingebauten basieren auf demselben Mechanismus und lassen sich genauso bearbeiten.
Es gibt acht Typen: Text, Zahl, Datum, Checkbox, URL, Auswahl, Mehrfachauswahl und Mitglied. Jeder bekommt auf dem Board das passende Filter-Element: Checkboxen für Auswahlfelder, einen Bereich für Zahlen und Daten, ein „Enthält“-Feld für Text. Filter werden mit UND kombiniert und stehen in der URL, ein gefiltertes Board ist also ein Link.
Auch dein KI-Agent sieht sie. Der MCP-Server gibt jede Eigenschaft mit ihren Optionen zurück, und list_tasks nimmt Eigenschaftsfilter an. „Offene Aufgaben, bei denen die Kundenstufe Enterprise ist“ ist also ein einziger Aufruf statt „alles holen und durchsuchen“.
Benutzerdefinierte Eigenschaften gibt es in Pro und Ultra, die fünf eingebauten, einschließlich der editierbaren Prioritätenliste, in jedem Plan.
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 Wörter deine eigenen sein müssen.
Bug-Tracking-Metriken, die wirklich zählen – vier Kennzahlen, die zeigen, ob dein Team mit den Bugs Schritt hält, und welche in die Irre führen.
Der Maschinenname, der zugleich der Anzeigename war – was im Code kaputtging, als die Prioritäten editierbar wurden, und wie ich es gefunden habe.