スクラムでの持ち越しタスクについて考えた
タスク持ち越しについて思うことを言語化した。
用語
この記事内での定義。
持ち越しタスク
スプリント内で完了できなかったタスクのこと。
スプリント内で完了できなかった場合はプロダクトバックログに戻して再見積もりする、場合によってはタスクを捨てるという話もあるので、完了できなかったタスクが必ずしもスプリントを跨いで持ち越されるわけではない。
ただ、この記事ではそう呼ぶ。
タスクを積む
そのスプリントで完了したいタスクを決めること。
気になること
価値を最大化するなら持ち越しがないほうが良い？
-
アジャイルが最大化するのは顧客に提供する価値である。
-
価値を最大化するためには、リソース効率ではなくフロー効率を高めたり価値の高いものから進めたりしなければならない。
-
フロー効率を高めるためには、並列で複数のプロジェクトを進めることは避けなければならない。
-
価値の高いものから進めるためには、頻繁にタスクの優先度を考え直さなければならない。
タスクを並列に進めてたくさん持ち越すのは 3 が実現できてない。優先度がきちんとついていれば、並列にタスクを進めることは少なくなりそう。
3, 4 を実現するなら、短いタイムボックス（スプリント）で完了できるタスクを積んで、全部完了した方が良いと思う。
1~4 の内容が正しいかはわからない。
持ち越してはいけないわけではない
タスクの持ち越しをしないことを目的にすると、以下の選択が許容されてしまう。
-
タスクを一切積まない
-
タスクを完了するまでスプリントの期間を延ばす
1 は価値の提供がまったくできなくなる。2 は期限を決めないことと同義なので、スプリントになってない。スプリントになってないと前述した価値を最大化するという点では良くないと言える。
持ち越しは想定外のこと？
持ち越しが発生する理由はいくつか考えられる。
-
タスクの積みすぎ
-
タスクの見積もりが間違っていた
-
ベロシティが下がっている
-
差し込みタスクが多い
-
コミュニケーションの問題が発生している
-
そもそもできると思ってタスクを積んでいるので、持ち越しが発生しているということは想定外のことが起こっているといえる。その想定外がどのくらいチームやプロジェクトに影響を与えるかによって、持ち越しを避けるモチベーションは変わりそう。
スプリントゴールが達成できているなら良い？
スプリントゴール＝積んだタスクの完了 ではないので、スプリントゴールさえ達成できれば積んだタスクを完了しなくても良いという考えもある。
どうする
-
スプリント内で完了できると思える量のタスクを積む
-
スプリントゴールはスプリントの 8 割ぐらいの期間で実現できることにする
-
残りの 2 割の期間で完了できそうな、持ち越してもあまり問題のないタスクを積む
ゴールは絶対、ただし予測は外れるかもしれないので、完了できない可能性を考慮してタスクを積むという戦略。
普通すぎない？