Time in Statusの中央値の合計はCycle Timeの中央値にならない

「そりゃそうだろ」と「え、そうなの」をよく右往左往するので、ブログにまとめておく。

Cycle TimeとTime in Status

まずはCycle TimeとTime in Statusの定義をおさらい。

Cycle Timeはある定義されたワークフローにおける「作業項目の開始してから終了までの経過時間」（From latest | カンバンガイド | カンバンガイド）。

Time in Statusはそのワークフロー内の各ステータスの滞留時間のこと。

例えば、ワークフローAは2つのステータス1、2（待ちやアクティビティ）からなっているとする。ステータス1に2日、ステータス2に5日滞留していたとすると、Cycle Timeは7日。

つまり、

\mathrm{Cycle Time} = \sum_i \mathrm{Time in Status}_i

一方で、

med(\mathrm{Cycle Time}) \neq \sum_i med(\mathrm{Time in Status}_i)

直感的にわかりそうでわからない。

例えば、

このとき、

\begin{align*} med(\mathrm{Cycle Time}) &= 101 \\ \sum_i med(\mathrm{Time in Status}_i) &= 2+3 = 5 \end{align*}

となる。逆に、

のときは、

\begin{align*} med(\mathrm{Cycle Time}) &= 101 \\ \sum_i med(\mathrm{Time in Status}_i) &= 99 + 98 = 197 \end{align*}

となり、こちらもCycle TimeとTime in Statusで乖離があるように見えてしまう。

このように同じステータスでもアイテムによってTime in Statusにばらつきがあったり、同じアイテムでもステータスによってTime in Statusにばらつきがある場合、Cycle Timeの中央値とTime in Statusの中央値の合計は全く違う値になる。

これはちなみに平均値だと起きない。

集計方法によるけど。

ここで言っているクロスファンクショナルチームとは、『 The New New Product Development Game 』のアプローチの分類のType B（Sashimi）やType C（Rugby）のようなチーム。

シーケンシャル開発とオーバーラップ開発の比較図

こういうチームは従来のフェーズ分けがオーバーラップするので、開発中かつテスト中みたいなことが起こる。各ステータスごとに開始日・終了日を独立して計測したりしてる場合、オーバーラップ部分はTime in Statusを合計すると重複して加算されることになる。

なので、こっちは平均値でもTime in Statusの合計とCycle Timeは一致しない。

思い切った数字を例で使うとわかりやすかった。