Lead Time und Cycle Time

Diese Begriffe werden oft verwechselt. Hier sind präzise Definitionen:

Lead Time: Die Gesamtzeit vom Zeitpunkt der Anforderung bis zur Auslieferung der Arbeit.

• Uhr startet: Wenn der Kunde/Stakeholder die Arbeit anfordert
• Uhr stoppt: Wenn der Kunde den Wert erhält

Cycle Time: Die Zeit vom Beginn der Arbeit bis zu ihrer Fertigstellung.

• Uhr startet: Wenn jemand mit dem Element zu arbeiten beginnt
• Uhr stoppt: Wenn die Arbeit abgeschlossen ist

Die Beziehung:

Lead Time = Cycle Time + Wartezeit (Warten vor Arbeitsbeginn)

Lead Time ist das, was Kunden interessiert. Cycle Time ist das, was das Team direkt kontrolliert. Beides ist wichtig.

Lead Time ist die Kundenerfahrung. Sie haben etwas angefragt – wie lange dauert es, bis sie es bekommen?

Kurze Lead Times bedeuten:

• Schnelleres Feedback zu Ideen
• Fähigkeit, auf Marktveränderungen zu reagieren
• Höhere Kundenzufriedenheit
• Wettbewerbsvorteil

Die Messung der Lead Time zeigt:

• Die vollen Kosten von Warteschlangen (oft 80%+ der Lead Time ist Warten)
• Wo das System Verzögerungen hinzufügt
• Ob Verbesserungen funktionieren

Die meisten Teams unterschätzen ihre Lead Time dramatisch, weil sie nur die Cycle Time sehen. „Das Feature hat 3 Tage Entwicklung gekostet" ignoriert die 3 Wochen im Backlog und die Woche Wartezeit auf Deployment.

Cycle Time ist die interne Effizienz des Teams. Wie schnell können wir Arbeit abschließen, sobald wir beginnen?

Kurze Cycle Times bedeuten:

• Weniger Work-in-Progress gleichzeitig
• Schnellere Feedbackschleifen
• Einfacherer Kontextwechsel
• Vorhersagbarere Lieferung

Die Messung der Cycle Time zeigt:

• Wie viel Variation existiert (wenig oder viel?)
• Welche Arbeitstypen länger dauern
• Ob das Team schneller oder langsamer wird

Die Variation ist genauso wichtig wie der Durchschnitt. Ein Team mit 5-Tage-Durchschnitt, aber 2-20-Tage-Spanne ist weniger vorhersagbar als eines mit 7-Tage-Durchschnitt und 5-10-Tage-Spanne.

Manuelle Erfassung (einfacher Start):

• Datum erfassen, an dem Arbeit in „In Bearbeitung" eintritt
• Datum erfassen, an dem Arbeit „Fertig" erreicht
• Differenz berechnen

Digitale Tools: Die meisten Kanban-Tools erfassen dies automatisch:

• Jira: Time in Status Report
• Linear: Cycle Time Analytics
• Trello: Mit Plugins
• Azure DevOps: Cycle Time Charts

Was zu erfassen ist:

• Einzelne Elementzeiten (für Trends und Analysen)
• Perzentile (50., 85., 95.) statt nur Durchschnitte
• Aufschlüsselung nach Arbeitstyp (Bugs schneller als Features?)
• Trend über Zeit (wird es besser oder schlechter?)

Vermeiden:

• Nur Durchschnitte verwenden (sie verbergen Variation)
• Wochenenden in Berechnungen einbeziehen ohne nachzudenken
• Verschiedene Arbeitstypen in eine Metrik mischen

Sobald Sie Cycle-Time-Daten haben, nutzen Sie sie für:

Prognosen: „85% der Elemente wie dieses werden innerhalb von 8 Tagen abgeschlossen. Ich kann guten Gewissens sagen, dass wir es bis nächsten Freitag haben."

Probleme identifizieren: „Dieses Element ist seit 12 Tagen in Bearbeitung. Unser 85. Perzentil liegt bei 8 Tagen. Etwas stimmt nicht – lasst uns nachforschen."

Verbesserungsvalidierung: „Letztes Quartal lag unsere mediane Cycle Time bei 5 Tagen. Dieses Quartal sind es 4 Tage. Unsere Prozessänderungen funktionieren."

Richtige Größe: „Große Features haben eine 3-mal höhere Cycle-Time-Varianz als kleine. Lasst uns Arbeit in kleinere Stücke aufteilen."

Die Erkenntnis: Cycle Time ist nicht nur ein Bericht – es ist ein Werkzeug, um im Moment bessere Entscheidungen zu treffen.