スクラム開発でのポイント部分消費による弊害
最近自分のチームでスクラム開発をやっています。
こちらの書籍を読んで理解を深める中で、ポイントの部分消費に関する問題点について気づいたのでまとめました。
ポイントの部分消費の問題点
ポイントの部分消費とは、例えば8ポイントのタスクの実装完了した段階で、5ポイントを消費して、残りの自動テストを3ポイントとして別チケットに残すようなことです。
ベロシティが信頼できなくなる
スクラム開発では、予測でなく実際に計測したベロシティを重視します。
ポイントの部分消費を認めてしまうと、誤魔化しが起きてしまい、重要な指標であるベロシティが信頼できなくなってしまいます。
- 実際には半分しか終わってないのに9割終わったことにしてポイントを消化する
- 9割終わったと思っていたが、実はまだ半分しか終わっていなかった
このようなことが起こりベロシティが信頼できなくなることで、未来の予測も立てづらくなってしまいます
品質の低下が起こる
ポイントの部分消費を認めると完了定義を誤魔化せるようになります。
例えばある機能の完了の定義が以下だったとします
- 実装
- リファクタリング
- 自動テスト
- ドキュメント作成
開発が思った通りに進まなかった時に、実装だけ完了して、自動テストやリファクタリングは別チケットに切り直して、後回しにすることが発生します。
その結果ベロシティは問題なく見えても品質の低いコードが量産されます。
見積もり精度向上の機会が失われる
ポイントの部分消費を認めてしまうと、見積もりに明確に失敗したことが認知されづらいので、振り返りの機会が失われます。
例えば5ポイントのタスクで、1週間程度で終わる予定だったものが、2週間かかると問題として認識しやすいです。
しかし3ポイントを部分消化して、次に残り部分を5ポイントとして積み直すみたいなことをすると、どこの見積もりが問題だったのか認識しづらくなります。
経験から改善することを重視するスクラム開発なのに、その機会を失ってしまいます。
どうすればいいのか
タスクをなるべく小さく切り、ポイントの部分消費を認めない
ポイントの部分消費の弊害はありますが、一方で完了したポイントが即座に計上されないと、進捗が分かりにくくなります。
例えば13ポイントのタスクがずっと持ち越されると進捗が分かりづらくなります。
そのため最初からなるべく小さいポイントになるようにタスクを分解して、さらにポイントの部分消費を基本的には認め無いのがいいかなと考えました。
Discussion