Nicht jedes Scrum Team ist immer in der Situation, dass das, was es fertiggestellt hat, auch direkt an den Kunden ausgeliefert wird. Es gibt eine Vielzahl von Gründen, warum beispielsweise feste Release-Zyklen existieren und Updates für Kunden nur einmal im Vierteljahr erfolgen. In solchen Fällen kann es für eine Organisation sinnvoll sein, neben der Lead Time & Cycle Time auch die Customer Cycle Time zu messen.
Was misst die Customer Cycle Time?
Ursprünglich stammt diese Metrik aus dem Evidence-Based Management, kann jedoch auch in Kanban oder Scrum eingesetzt werden.
Die Customer Cycle Time misst die Zeit, die benötigt wird, bis ein neues Feature (oder anderes Work Item) wirklich vom Kunden genutzt werden kann, nachdem damit begonnen wurde, es umzusetzen.
Damit ist die Customer Cycle Time immer dann sinnvoll, wenn Deine Organisation in festen Release-Zyklen arbeitet und Deine Scrum Teams ein Update nicht nach jedem Sprint (oder noch früher) an ihre Kunden und Nutzer ausliefern.
Cycle Time vs. Lead Time vs. Customer Cycle Time
Um Dir das Konzept hinter der Customer Cycle Time zu verdeutlichen, habe ich hier einmal den Workflow eines Scrum Teams visualisiert, deren fertige Arbeit für einige Zeit gesammelt wird, um dann in festen Release-Zyklen an die Kunden geliefert zu werden.
Durch diesen Workflow entstehen für die drei Metriken vollkommen unterschiedliche Werte.
Fazit zur Metrik
Die Customer Cycle Time kann damit sehr hilfreich sein, um Probleme einer Organisation sichtbar zu machen, die nicht in „langsamen Teams“ begründet sind, sondern in ihrer Fähigkeit, den Nutzen auch zum Kunden zu bringen.
Ein recht häufiger Reflex, wenn Kunden ausbleibende Updates bemängeln, ist es nämlich, die Arbeit in den Teams zu beschleunigen. Wenn sich aber der wahre Grund an anderer Stelle im Unternehmen befindet (nämlich in einer viel zu langen Delivery-Phase), kannst Du diesen Umstand mit Hilfe der Customer Cycle Time sicht- und vor allem diskutierbar machen.
