Done の定義

スクラムの検査と適用のサイクルを効果的にするためには、透明性が求められます。
Done の意味を正式に定義することで、タスクがDoneかUndoneか曖昧になったり、Undoneのままになったりする可能性を減らし、進捗状況（Doneか、Undoneか）を明確に測定できるようになるため、透明性が向上します。

完璧なDoneの定義は、組織がプロダクトを顧客に提供するために必要な全てのことを包含します。
単一チームの場合、完璧なDoneの定義を達成することは比較的容易なはずです。
チームが完璧なDoneの定義を達成できない場合は、その部分集合を Doneの定義とします。チームのゴールは、Doneの定義を洗練し、いつの日にか完璧なDoneの定義にし、毎スプリント出荷可能な状態を作ることです。

Doneの定義は、ソフトウェアが各PBIで達成する、合意済みの基準のリストです。
このレベルの完全性を達成するために、チームは一連のタスクを実施する必要があります。全てのタスクが完了したら、そのPBIはDoneと言えるのです。
Doneの定義を受入条件と混同しないようにしてください。受入条件は個別のPBIが受入可能になるために満たすべき条件です。Doneの定義は全てのPBIに一律に適用される条件です。

Doneの定義をつくる

最初のDoneの定義は、1度目のスプリントが始まる前に合意されている必要があります。
これはたいてい、初期プロダクトバックログリファインメントにて合意されます。

Doneの定義を作るためには、以下の手順を踏みます。

顧客に提供するために必要な営みを定義する
その営みのうち、どれを毎スプリト中に実施するか決める

これらの手順の詳細をみていきましょう。

顧客に提供するために必要な営みを定義する

鍵となる問いは、「今、どの営みが我々のプロダクトを出荷するために必要か」です。

出荷は「顧客にプロダクトを届けること」を意味します。「開発部門の手を離れること」ではありません。
中間成果物の必要性に疑問を投げかけましょう。仕様書は、本当に必須でしょうか。

チームは必要な営みを付箋に書き出します。
これらはコーディングやテストだけでなく、カスタマーサポートの設立、ハードウェアの構築、あるいはマーケティング活動なども含まれるかもしれません。
私たちはこのリストを「潜在的に出荷可能なプロダクト」を手に入れるために必要な営みの一覧と見なします。

このステップで、あなたは組織の完全なゴールを作り上げます。
全ての営みを毎スプリント、全てのPBIにて実施しましょう。プロダクトグループは、多くの場合、このためには数多くの改善が必要だと気づくでしょう。

どの営みを毎スプリト中に実施するか決める

鍵となる問は、「現在の状況とキャパシティを考え、どの営みなら毎スプリト完遂できるか」です。
この部分集合が、はじめの「Doneの定義」となります。
部分集合の範囲が狭いものは「弱いDoneの定義」、潜在的に出荷可能な条件とほぼ同一なら「強いDoneの定義」です。

全チームで自分たちの状況を話し合い、全てのチームが現実的にSprint中で実施可能と感じる営みを選びます。
選び出した集合が、初期の「Doneの定義」です（図1）。
全チームが、「もっと出来る」と感じたら、Doneの定義を拡張します。

「Doneの定義」と「潜在的に出荷可能」の差分は、「Undoneワーク」と見なされます。
スプリント計画は、Doneの定義を踏まえて立てられるので、 Undoneワークは計画から除外され、Undoneのまま残置されます。

Doneの定義に関する用語

「潜在的に出荷可能」と「Doneの定義」は一貫した意味をもたないケースも多いですが、LeSSでは明確な意味を規定しています。

潜在的に出荷可能—プロダクトを出荷可能にするために必須な全ての営み

Doneの定義—チームとプロダクトオーナーが、どの営みをSprint中に実施するか合意したもの。「潜在的に出荷可能」と一致する場合は「完璧なDoneの定義」と呼ぶ。チームは完璧なDoneの定義を目指して改善するよう努めます。

Undoneワーク—Doneの定義と潜在的に出荷可能の間にある差分。Doneの定義が完璧なら、Undoneワークは存在しません。そうでない場合、組織は以下の決断を下します。(1)Undoneワークにどう対処するか。 (2)将来Undoneワークを減らすために、どんな改善を行うか。

未完了、完了していない、Doneでない—スプリント中に計画されていたが、完了しなかったタスク。これらはUndoneワークが原因で発生する事が多いです。「Undoneワーク」が計画自体されないのに対し、「未完了」は計画されたが終わらせることが出来なかったものを指します。
完了できなかったタスクがあったとき、チームはこの事実を気にかけて、振り返りの時間に改善方法を議論すべきです。

チームは、Sprintの終わりにタスクを作業中のまま次Sprintに引き継ぐことを避けるべきです。
これを行うと、透明性が欠如し、スコープの柔軟性を低下させます。
もし、計画したタスクが多すぎることに気づいたときは、未着手のPBIをまるごと計画から取り除くべきです。

Doneに関する数式

潜在的に出荷可能 = Doneの定義 + Undoneワーク
イテレーション中の作業 = PBI * Doneの定義

Undoneワーク -> リスクと遅延

はじめに、シナリオをたどりながら、Undoneワークの効果を調べてみましょう。

チームは、第1Sprintで、Doneの定義に従って、20のPBIを完了しました。
「未完了」のタスクはありませんでしたが、Doneの定義が弱いため、たくさんのUndoneワークが存在しました。
その後、チームは 3つのSprintで、彼らの弱いDoneの定義に従って、40のPBIを完了しました。Undoneワークの数はどんどん増えて、進捗に関する誤解を引き起こしています。

しかし彼らは出荷できません。
彼らは、フィーチャをDoneにしてきましたが、弱いDoneの定義は膨大なUndoneワークを生み出しているのです。これらのUndoneワークは、遅延と隠れたリスクを発生させます。

遅延—Undoneワークに対処するためには追加の努力が必要です。これは柔軟性の欠如をもたらし、プロダクトオーナーは市場のニーズや変化に直接対応出来なくなります。Undoneワークを完了するための努力は非常に変動的で予測しにくいため、この遅延による痛みはより悪化します。

リスク—Undoneワークは透明性の欠如を引き起こします。リスクはそこに隠蔽されます。
例えば、もし性能テストがUndoneの場合、性能問題の露呈をリリースの直前–最悪のタイミング–まで遅らせることになりかねません。

良いプロダクトオーナーは、プロダクトのリスクを減らし、遅延を回避するために完璧なDoneの定義を求めます。