Simyl
simylflow
Kursübersicht
Modul 2: Arbeit & Flow visualisieren
Lektion 4 von 5
12 Min.

Classes of Service

Verschiedene Arbeitstypen entsprechend ihrer Verzögerungskosten behandeln.

1Jenseits von Prioritätsnummern

Traditionelle Priorisierung (P1, P2, P3 oder Hoch/Mittel/Niedrig) hat Probleme:

  • Alles wird „hohe Priorität"
  • Prioritäten spiegeln die wirtschaftliche Realität nicht wider
  • Keine klare Richtlinie, wie jede Stufe zu handhaben ist

Classes of Service lösen dies, indem sie Arbeit nach den wirtschaftlichen Folgen einer Verzögerung kategorisieren – den Verzögerungskosten.

Die vier Standardklassen sind:

  1. Expedite: Verzögerung hat schwerwiegende, unmittelbare Kosten
  2. Fixed Date: Verzögerung über eine Frist hinaus hat schwerwiegende Kosten
  3. Standard: Verzögerungskosten sind linear (längeres Warten = proportional schlechter)
  4. Intangible: Verzögerungskosten sind unklar oder sehr gering

Die Kernidee

Classes of Service geht es nicht darum, wie wichtig Arbeit ist – sondern darum, wie zeitsensibel sie ist. Ein kritisch wichtiges Feature ohne Frist ist Standard, nicht Expedite.

2Expedite-Klasse

Definition: Arbeit, bei der Verzögerung unmittelbare, schwerwiegende Folgen hat.

Beispiele:

  • Produktion ist ausgefallen
  • Sicherheitslücke entdeckt
  • Regulatorische Frist morgen
  • Großkunde droht abzuspringen

Richtlinien für Expedite:

  • Maximal 1 Element in Expedite gleichzeitig
  • Lässt alles andere fallen (sogar WIP-Limits)
  • Muss aktiv bearbeitet werden, bis es fertig ist
  • Erfordert explizite Genehmigung (nicht selbst zugewiesen)
  • Löst Ursachenanalyse danach aus (warum war dies dringend?)

Der Test: Wenn Sie diese Arbeit in 2 Tagen statt in 1 Tag abschließen würden, würde etwas Schreckliches passieren? Wenn ja, könnte es Expedite sein. Wenn nein, ist es wahrscheinlich Standard.

Warnzeichen für Missbrauch:

  • Mehr als 10 % der Arbeit ist Expedite
  • Expedite-Lane ist nie leer
  • Leute nutzen Expedite, um die Warteschlange zu überspringen

3Fixed Date-Klasse

Definition: Arbeit, die bis zu einem bestimmten Datum abgeschlossen sein muss, nach dem sie erheblich an Wert verliert.

Beispiele:

  • Black-Friday-Sale-Features
  • Regulatorische Compliance-Frist
  • Partner-Launch-Verpflichtung
  • Konferenz-Demo

Richtlinien für Fixed Date:

  • Muss explizites Datum haben
  • Wird früher priorisiert basierend auf Durchlaufzeit-Anforderungen
  • Kann Kapazität reservieren, um Fertigstellung sicherzustellen
  • Regelmäßige Check-ins, wenn Frist näher rückt

Die zentrale Erkenntnis: Fixed Date-Arbeit muss früher beginnen, nicht schneller ablaufen. Wenn Ihre durchschnittliche Durchlaufzeit 10 Tage beträgt, sollte ein Fixed Date-Element, das in 12 Tagen fällig ist, jetzt beginnen, nicht in 2 Tagen.

Anders als Expedite lässt Fixed Date nicht alles fallen – es stellt nur sicher, dass die Arbeit früh genug beginnt, um rechtzeitig fertig zu werden.

Gute Fixed Date-Handhabung

Ein Compliance-Feature ist in 3 Wochen fällig. Die durchschnittliche Durchlaufzeit beträgt 2 Wochen. Das Team beginnt jetzt damit, überwacht den Fortschritt und hat Puffer für Probleme.

Schlechte Fixed Date-Handhabung

Ein Compliance-Feature ist in 3 Wochen fällig. Das Team behandelt es als „noch nicht dringend" und beginnt damit, wenn noch 1 Woche übrig ist. Heldentaten folgen.

4Standard-Klasse

Definition: Arbeit, bei der die Verzögerungskosten ungefähr linear sind – längeres Warten ist proportional schlechter, aber nicht katastrophal.

Beispiele:

  • Die meiste Feature-Entwicklung
  • Normale Bugfixes
  • Interne Verbesserungen
  • Kundenanfragen ohne harte Fristen

Richtlinien für Standard:

  • FIFO (First In, First Out) innerhalb der Klasse
  • Unterliegt normalen WIP-Limits
  • Keine Sonderbehandlung

Dies ist Ihr Standard. Die meiste Arbeit sollte Standard sein. Wenn Ihre Expedite- und Fixed Date-Lanes ständig voll sind, stimmt etwas nicht – entweder mit Ihrem System oder damit, wie Arbeit klassifiziert wird.

5Intangible-Klasse

Definition: Arbeit, bei der die Verzögerungskosten unklar, sehr gering sind oder sich erst in ferner Zukunft manifestieren werden.

Beispiele:

  • Abbau technischer Schulden
  • Dokumentationsverbesserungen
  • Explorative Forschung
  • „Nice to have"-Features
  • Proaktive Wartung

Richtlinien für Intangible:

  • Niedrigere Priorität als Standard
  • Kann dedizierte Kapazitätszuweisung haben (z. B. 20 %)
  • Funktioniert als „Lückenfüller", wenn nichts anderes wartet
  • Regelmäßig überprüft – lohnt es sich noch?

Die Falle: Intangible-Arbeit wird nie erledigt, weil Standard-Arbeit unendlich ist. Lösung: Explizite Kapazität zuweisen. „Wir verwenden 15 % der Kapazität für technische Schulden" schützt diese Arbeit.

Die andere Falle: Intangible-Arbeit ist tatsächlich wertvoll, nur mit verzögerter Amortisation. Sie zu ignorieren schafft später Probleme. Verfolgen Sie sie separat, damit Sie sehen können, ob Sie genug investieren.

Wenn Sie in einem Monat keine Intangible-Arbeit erledigt haben, häufen Sie wahrscheinlich unsichtbare Schulden an. Nehmen Sie sich bewusst Zeit dafür.

6Classes of Service implementieren

Option 1: Swimlanes pro Klasse Am visuellsten und klarsten. Vier horizontale Lanes, Arbeit fließt von links nach rechts innerhalb jeder Lane. Expedite oben, Intangible unten.

Option 2: Kartenfarbe oder Tag Weniger visuelle Wirkung, funktioniert aber, wenn Sie Swimlanes bereits für etwas anderes verwenden.

Option 3: Separates Expedite-Board Manche Teams ziehen dringende Arbeit auf ein dediziertes „Kriegsraum"-Board, bis sie gelöst ist.

Zu etablierende Richtlinien:

  • Wie wird Arbeit klassifiziert? (Wer entscheidet, welche Kriterien?)
  • Kann Arbeit die Klasse wechseln? (Normalerweise: nach oben ist einfach, nach unten erfordert Diskussion)
  • Welche Kapazität geht an jede Klasse?
  • Wie oft wird die Klassifizierung überprüft?

Fangen Sie einfach an: Nur Expedite und Standard. Fügen Sie Fixed Date hinzu, wenn Sie echte fristgebundene Arbeit haben. Fügen Sie Intangible hinzu, wenn Sie bereit sind, Investitionsarbeit zu schützen.

Wichtige Erkenntnisse
  • Classes of Service kategorisiert Arbeit nach Verzögerungskosten, nicht nach Wichtigkeit
  • Expedite, Fixed Date, Standard und Intangible haben unterschiedliche Richtlinien
  • Die meiste Arbeit sollte Standard sein – wenn nicht, stimmt etwas nicht
  • Intangible-Arbeit braucht geschützte Kapazität, sonst passiert sie nie
Häufige Fehler, die es zu vermeiden gilt
  • Alles als Expedite markieren (macht den Zweck zunichte)
  • Keine Kapazität für Intangible-Arbeit zuweisen
  • Klassen wie Priorität statt Zeitsensibilität behandeln
  • Fixed Date-Fristen verpassen, weil nicht früh genug begonnen wurde