スクラムにおいてプロダクトバックログと並び非常に重要なのは、完了の定義(Definition of Done)です。完了の定義を洗い出し、合意することでわかってくることがあります。また、完了の定義をきちんと決めることによって、スクラムを厳しい規制開発環境下でも活用可能かが変わってきます（例えばFDA認可プロダクトや、ISO*****が必要なプロダクト）。また、そのプロダクトにスクラムが適用可能かどうかもわかってきます。４週間を超えるスプリント期間がどうあがいても必要だったり、後に記載する未完了(UNDONE)が多すぎる場合は、スクラムは適さないプロダクト開発である可能性が高いです。完了の定義のないスクラムはスクラムではありません。

完了の定義を決めることでわかってくること

・スプリントが完了してから、ユーザにプロダクトをリリースできるまでのおおよその期間。（未知のプロダクトを作っている際には、プロダクト開発開始時は完了の定義が決めきれないことが多いが、決めきれないながらもPOと開発チームで議論することが重要であり、完了の定義はそのきっかけ作りとなる）
・スプリント内で、開発チームがタスクを完了させる際に、やるべきことがPO・開発チームで合意され、共有される。
・スプリントの期間（１週間、２週間、３週間、４週間のいずれか）を決めるための要素となる。

完了の定義をいつ決めるべきか

　プロダクトオーナーは、スプリントの開始前と開始後数スプリントは、完了の定義を意識するべきです。なぜなら、潜在的にリリース可能なインクリメントをスプリント毎にリリースしていきますが、”潜在的な”の部分に、残りどれくらいの作業と費用が必要なのか、もしかしたら開発チームだけでまかないきれない非常に専門的なことがあるかも知れず、当初予定していた予算やリリース日から大幅にずれてくることが予見されるからです。例えば、ヘルプファイルの作成とリリースをスプリントに含めるべきか否か、規制を守るためのドキュメントの作成・更新・最終的な提出など。
　また、完了の定義は開発チームやプロダクトオーナーがスプリントを重ね、学びを得ると更新されていくものでもあります。開発チームとスクラムマスターは、完了の定義を拡張していくために、振り返りの時間やスプリント内の時間（プロダクトバックログリファインメントでもいいし、特別な時間を設けても良い）を使って議論とプロダクトバックログアイテムの追加を行います。

完了の定義の決め方

　スクラムは経験主義的なプロセスなので、「予めすべての計画を立てておくことはできない」という考えに基づいています。試しながら学び、学びを積みかさねるプロセスです。当然、完了の定義を最初からすべて決められる訳ではありません。しかし、なるべく最初にある知識を総動員して、その時点で完了の定義だと思われるものを決めます。
　まず、これまでのプロダクト作りの経験から、プロダクトをリリースする（顧客の元へ届け、顧客が使い始められる状態）までにどのような作業が必要かを洗い出します。例えば、ソフトウェア開発では、以下のような作業が洗い出されると思います。
・基本設計書が記載され、レビューされている。
・コードが書かれている。（※ソフト開発においてコードが書かれているのはあたりまえなので、わざわざ完了の定義には記載しないことが多い）
・コードがレビューされている。
・コードがコード管理システムのチェックインされている。
・コードをCIでビルドし、実行ファイルを作成する。
・自動テストが記載されて、パスしている。
・すべてのパフォーマンステストに、パスしている。
・インストーラーを作成する
もちろん、開発をおこなう企業やコミュニティなどで必要となる作業が異なってくると思いますが、あくまで「プロダクトをリリースする」までに必要な作業を洗い出します。

完了(DONE)と未完了(UNDONE)

　その後、１スプリント内でどの作業までできそうかを開発チームが検討します。ここでスプリントの期間が決まってきます。スプリントの期間内でできる作業を「完了（DONE）」、期間内でできない作業を「未完了（UNDONE)」と呼び、区別します。「未完了（UNDONE)」は、開発のスプリント内で出来ないものですから、負債となります。この負債は、スプリントを重ねる毎に溜まっていきます。開発チームやプロダクトオーナーは、この負債を意識しておく必要があります。開発スプリント後に着手する必要のあるものだからです。これを意識して、例えば、数スプリントに１回はUNDONEに着手し、少しでも負債を減らすこともできます。開発スプリント後のUNDONEな作業をやっつけていく期間を、リリーススプリント、もしくは開発チームで賄えない場合は、UNDONE担当チームが、UNDONEを担当します。本来、スクラムはクロスファインクショナルなフィーチャーチームが望ましいと言われているので、リリーススプリントやUNDONE担当チームはアンチパターンとなりますが、それをアンチパターンだと意識してスクラムに臨むことが大切です。UNDONEの作業を開発スプリント内で着手できるようにすることを「DONEの拡張」といいます。スクラムマスターと開発チームは「DONEの拡張」を行うために、頭をひねることになります。基本的には、スプリント毎にリリースするのが最も望ましい状態です。なぜなら、顧客からのフィードバックが一番学べる機会だからです。

完了の定義と受け入れ条件（アクセプタンスクライテリア）の違い

　よく混同されますが、完了の定義は、非機能品質的な要素が強く、受け入れ条件は機能品質的な要素が強いです。
　受け入れ条件を最終的に決めるのは、プロダクトオーナーですが、完了の定義は、プロダクトオーナーと開発チームの合意の元で決めます。完了の定義はプロダクト全体がスコープになり、受け入れ条件はプロダクトバックログアイテム毎に決められます。

完了の定義を決めるワークショップ

　もし必要であればご連絡いただければ、完了の定義を決めるワークショップができます（笑