スクラムにおける DONE と UNDONE について
TL;DR
UNDONE とは、 DONE を全て完了したにも関わらずリリースできない状況のギャップに存在する作業のことであり、 Definition of DONE 同様に明示的に取り扱われなければならない作業群のことである。
概要
スクラムの概念の中でややわかりづらいとされる DONE と UNDONE。
言葉どおり受け取ると、DONE と UNDONE はそれぞれが補集合であるように見えるが、実際には、それぞれ違うものを意図的に扱っている。
スクラムが理想とする世界
まずは、スクラムが理想としている世界、特に「出荷」(ここでは単純化のためリリースのことを出荷として扱う) について改めて。
スクラムでは、常にリリース可能である状態を維持することが理想とされている。
これによってプロダクトオーナーが求める頻度で顧客に価値提供が可能になり、フィードバックを得る頻度をコントロールすることができるようになる。
つまり、あるプロダクトバックログアイテムを完了した瞬間リリース可能である状況が理想的である。
例えば、プロダクトオーナーが机に近づいてきて、 「このプロダクトバックログアイテムを完了したら顧客の反応を確認したいのでリリースしてくれないか？」 と言われたら即座にリリースできる状態がチームとしてのアジリティが高い状態が保てていることになる。
DONE できないものは、 INCOMPLETE
スクラムが理想とする世界において、バックログアイテムの「完了」の条件を明示的に定義しているのが、 Definition of Done (Doneの定義) である。
ここで勘違いが起きやすいのだが、スプリント内で Definition of Done (Doneの定義) を満たせずに「完了」できなかったものは、 UNDONE ではない。
あえていうならば、 INCOMPLETE (不完全) の状態である。1
単純にプロダクトバックログアイテムをタイムボックスの中で完了することができなかったというだけである。
UNDONE
では、 UNDONE とはなにか。
再三述べているように、スクラムが理想的な状態になっているとすると、 バックログアイテムが DONE していればリリースが可能なはずである。
しかし現実には、様々な要因で「完了」しているがリリースができないという状況が存在する。
例えば、以下のような作業が残ってしまう
- アプリの審査提出
- 社内規定の品質テストやパフォーマンステストなど
- …
つまり、 UNDONE とは全てのプロダクトバックログアイテムが完了しているにも関わらずリリースができないというギャップに存在する作業のことなのである。
そして重要なことにこれらも Definition of Done 同様に明示的に示されている必要がある。
またスクラムチームとしては、理想状態に近づけるためになるべく UNDONE を減らし、 Definition of DONE を強化していくことに力を入れていかなければならない。(e.g. 品質テストの自動化など)
最終的には必要最低限の UNDONE のみを UNDONE として取り扱うというのが目指すべきスクラムチームなのかなと思うなどした。