Öffne einen beliebigen Bug-Tracker, und du findest dieselben vier Wörter: niedrig, mittel, hoch, kritisch. Sie sind so üblich, dass niemand sie hinterfragt. Für die meisten Teams sind sie trotzdem falsch, nicht weil vier die falsche Zahl wäre, sondern weil die Wörter von jemand anderem stammen.
Eine Prioritätsskala ist eine komprimierte gemeinsame Entscheidung
Ein Prioritätsfeld soll den Bug nicht beschreiben. Es soll eine Frage beantworten, für alle, die als Nächste aufs Board schauen: Arbeite ich daran vor dem, woran ich eigentlich arbeiten wollte?
Damit ist eine Prioritätsstufe eine komprimierte Vereinbarung. „Kritisch“ heißt in deinem Team etwas Bestimmtes: vielleicht „jemanden aus der Rufbereitschaft holen“, vielleicht „kommt in den nächsten Patch“, vielleicht „Release stoppen“. Das Wort funktioniert nur, wenn alle es gleich entpacken.
Genau deshalb verwässert eine generische Skala. Niemand hat vereinbart, was „hoch“ in deinem Tracker bedeutet, also bringt jede Person ihre eigene Definition mit, und das Feld transportiert keine Information mehr.
Die zwei Fragen, die verwechselt werden
Die meisten Diskussionen über Priorität drehen sich eigentlich um zwei verschiedene Fragen:
Schweregrad (Severity): Wie schlimm ist der Fehler? Ein Absturz ist schwerwiegend. Ein verrutschtes Icon nicht.
Priorität: Wann wird er behoben? Ein verrutschtes Icon auf der Preisseite eine Stunde vor einem Launch ist dringend, aber nicht schwerwiegend.
Ein einzelnes Feld kann nicht beides abbilden, und Teams, die es versuchen, landen bei einer Skala, die montags Schweregrad bedeutet und freitags Priorität. Entscheide dich für eins – für die meisten Produktteams ist die Priorität das nützliche, weil sie ändert, was du als Nächstes tust –, und wenn du wirklich beides brauchst, mach den Schweregrad zu einem eigenen Feld.
Wie viele Stufen
Weniger, als du denkst.
Eine lange Skala scheitert nicht daran, dass Leute falsch wählen, sondern daran, dass sie aufhören zu wählen. Mit P0 bis P4 nutzen die meisten Teams P1 und P3 und lassen den Rest still liegen. Du hast eine Skala mit fünf Stufen, die die Arbeit von zwei macht.
Ein Test: Kannst du für jedes benachbarte Paar von Stufen eine Regel nennen, die ohne Nachdenken zwischen ihnen entscheidet? Wenn sich „hoch“ und „mittel“ nur im Gefühl unterscheiden, sind sie eine Stufe mit zwei Namen.
Drei Stufen, die alle gleich anwenden, schlagen fünf, bei denen geraten wird. Bei vier landen viele Teams, weil es dann zwei Varianten von „bald“ und zwei von „später“ gibt.
Die andere Regel: Die oberste Stufe muss selten sein. Wenn ein Drittel des Boards kritisch ist, wurde das Wort zu „das ist mir wichtig“ umgedeutet, und das Board sagt dir nicht mehr, wo du anfangen sollst. Eine nützliche oberste Stufe beschreibt etwas, wofür du die Arbeit unterbrechen würdest, und das kann schon per Definition kein Drittel von irgendwas sein.
Benenne sie so, wie dein Team spricht
Wenn im Stand-up gefragt wird „Ist das ein Blocker?“, dann sollte Blocker ein Wert im Tracker sein. Jeder Übersetzungsschritt zwischen dem, wie Leute sprechen, und dem, was das Tool anbietet, ist eine Stelle, an der das Feld falsch ausgefüllt oder übersprungen wird.
Das ist das stärkste Argument für editierbare Prioritäten, und es hat nichts mit Flexibilität als Selbstzweck zu tun. Ein Feld, das Leute in ihrem eigenen Vokabular beantworten können, ist ein Feld, das sie tatsächlich beantworten.
Ein paar Skalen, die du übernehmen kannst:
Support-getriebene Teams: Blocker · Dringend · Normal · Niedrig – passt sauber auf ein SLA.
Produktteams: Jetzt · Als Nächstes · Später – drei Stufen, keine Mehrdeutigkeit, taugt gleichzeitig als Roadmap.
Arbeit, die wie Incidents aussieht: P0 · P1 · P2 – wenn dein On-Call-Runbook diese Nummern schon nutzt, nimm hier dieselben.
Die Skala in BugDump bearbeiten
BugDump startet jedes Projekt mit Niedrig, Mittel, Hoch und Kritisch, und keine davon ist fest. Wähle auf der Seite Eigenschaften die Priorität aus und bearbeite die Liste: direkt umbenennen, umfärben, eigene hinzufügen, löschen, was du nicht nutzt.
Eine Umbenennung wirkt überall gleichzeitig. Aufgaben, die schon als Kritisch markiert sind, zeigen das neue Wort auf ihren Karten, im Aufgaben-Panel, im öffentlichen Portal und über den MCP-Server. Es gibt keine Migration und kein Neu-Taggen, weil die Aufgabe auf die Option zeigt, statt eine Kopie ihres Namens zu speichern.
Wenn du eine Stufe löschst, bleiben ihre Aufgaben erhalten, sie verlieren nur diese Priorität. Eine überplante Skala auszudünnen ist also billig, und das zählt, weil die meisten Teams die richtige Skala erst finden, nachdem sie einen Monat lang mit der falschen gearbeitet haben.
Das Board filtert nach allem, was in deiner Liste steht, auch nach mehreren Stufen gleichzeitig.
Zwei Dinge, auf die du beim Umbenennen achten solltest
Alles, was eine Priorität über ihren Namen setzt. Ein eingebettetes Widget, das priority: 'critical' übergibt, oder ein Script, das die API aufruft. Der Abgleich ignoriert Groß- und Kleinschreibung, also findet critical weiterhin Critical. Wenn du Kritisch aber in Blocker umbenennst, passt der alte Name auf nichts mehr. Anonyme Berichte kommen trotzdem an, nur ohne Priorität. Authentifizierte Aufrufe werden abgelehnt, damit du es merkst.
Integrationen, die auf eigene Schweregrade abbilden. Jira und Freshdesk haben eigene Skalen, und eine Stufe, die du erfunden hast, hat dort kein Gegenstück, also bekommen diese Tickets den mittleren Schweregrad des Ziels. Wenn dieses Mapping wichtig ist, füge Stufen hinzu, statt die Standardstufen umzubenennen.
Ehrlich zusammengefasst
Die Priorität ist ein kleines Feld, das die Reihenfolge von allem anderen bestimmt, und sie funktioniert nur, wenn ein Team wirklich vereinbart hat, was jede Stufe bedeutet. Ein festes Vokabular steht dieser Vereinbarung im Weg. Lass stattdessen den Tracker deine Wörter lernen.
Und dann nutze die Skala mit etwas Disziplin: Halte die oberste Stufe selten, lösch die Stufe, die niemand wählt, und schau sie dir nach einem Monat mit echten Bugs noch einmal an.
Bug-Tracking-Metriken, die wirklich zählen – vier Kennzahlen, die zeigen, ob dein Team mit den Bugs Schritt hält, und ein wöchentlicher Check in fünf Minuten.
Bugs schneller triagieren: ein Workflow für die Tastatur – wie Triage schneller wird, wenn die Navigation drumherum wegfällt, nicht das Nachdenken.
Benutzerdefinierte Felder im Bug-Tracker: was sich lohnt und was nicht – der Test, der ein nützliches Feld von einem trennt, das in sechs Wochen leer ist.