4 2 Stimmen
Artikel-Rating

Nicht jedes Team ist in der Lage, das, was es in einem Sprint fertiggestellt hat, auch direkt an den Kunden auszuliefern. Es gibt eine Vielzahl von Gründen, warum es feste Releasezyklen gibt und Updates für Kunden beispielsweise nur einmal im Vierteljahr erfolgen. In solchen Fällen kann es für eine Organisation sinnvoll sein, die Customer Cycle Time aus dem Evidece-Based Management zu nutzen.

Was misst die Customer Cycle Time?

Die Customer Cycle Time misst die Zeit, die benötigt wird, bis ein neues Feature vom Kunden genutzt werden kann, nachdem damit begonnen wurde, es herzustellen.

Damit ist die Customer Cycle Time immer dann sinnvoll, wenn Deine Organisation in Release-Zyklen arbeitet und Scrum Teams nicht nach jedem Sprint ein Update (oder noch früher) an ihre Kunden und Nutzer ausliefern. Wenn wir einmal die Time to Learn Phasen dazu zu Rate ziehen, dann ist der Unterschied in der Phase Delivery zu entdecken.

Scrum Teams, die direkt nach jedem Sprint neue Updates ausliefern, würden die Phasen Build und Delivery als Doing betrachten. Sobald der Kunde ein neues Feature nutzen kann, zählt es als Done. Scrum Teams, die zwar in Sprints arbeiten, aber deren Updates mit einem festgelegten Release-Zyklus veröffentlicht werden, würden nur die Phase Build als Doing betrachten und alle Features, die in die Delivery-Phase übergehen bereits als Done.

Time to Learn Phasen (Features) Sketch (Idea) Build Deliver Use Learn
Status (Delivery direkt nach Sprint) To Do Doing Doing Done Done
Status (Delivery in Release-Zyklen) To Do Doing Done Done Done

Durch die festen Releases ergibt eine Customer Cycle Time Sinn, wenn Du wissen möchtest, wie lange Deine Organisation benötigt, Nutzen zum Kunden zu bringen.

Mehr erfahren!

Praxisorientiertes Netzwerken & flexibles Lernen - vereint in einem einzigen Kurs!

Agile Strategy verbindet Dich nachhaltig mit einem kollaborativen Netzwerk aus Gründern, Freelancern, Product Ownern & Sidepreneuren. Mit erprobten Strategie- & Innovations-Tools bringen wir Deine Businessidee direkt in die Umsetzung – schnell, einfach & kostengünstig.

Mehr erfahren!

Einsatzbeispiel Customer Cycle Time

Ein Team benötigt im Durchschnitt 5 Wochen, um mit der Arbeit an neuen Features zu beginnen und liefert diese regelmäßig nach 2 Wochen fertig ab. Allerdings arbeitet die Organisation mit vierteljährlichen Release-Zyklen. Übertragen auf die Time-to-Learn-Phasen bedeutet das also:

Time to Learn Phasen (Features) Sketch (Idea) Build Deliver
Zeit pro Phase 5 Wochen 2 Wochen 3 Monate

Durch die Customer Cycle Time kannst Du nun sichtbar machen, dass es trotz einer niedrigen Lead & Cycle Time (7 bzw. 2 Wochen) ziemlich lange dauert, bis der Nutzen auch beim Kunden ankommt, nämlich 3,5 Monate.

Time to Learn Phasen (Features) Sketch (Idea) Build Deliver
Cycle Time 5 Wochen 2 Wochen 3 Monate
Customer Cycle Time 5 Wochen 3,5 Monate
Lead Time 7 Wochen 3 Monate

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 der 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 langen Delivery-Phase), kannst Du diesen Umstand über die Customer Cycle Time sicht- und vor allem diskutierbar machen.