スクラムではスプリントを始める前に「完成の定義」を作る。プロダクトバックログアイテムをどこまで作業したら「完成」とするかを定義し、スクラムチーム全員で合意する。
開発チームは、毎回のスプリントで「完成の定義」を満たすようインクリメントを作らなくてはならない。
「完成の定義」には2種類ある
- 強い「完成の定義」
- 弱い「完成の定義」
強い「完成の定義」とは、スプリント内でリリースにかかる大半の作業ができることを意味する。リリースまでの「未完成作業」が少ない状態だ。
一方、弱い「完成の定義」とは、スプリント内でリリースまでに必要な作業の大半ができないことを意味する。リリースまで「未完成作業」がたくさん残っている状態だ。
すなわち以下の数式が成り立つ。
- 「完成の定義」+「未完成作業」=リリースできるインクリメント
そして、即リリースできるインクリメントまでスプリント内で完成できることを「完璧な完成の定義」という。リリースまで未完成作業が皆無の状態だ。
「未完成作業」例:
- ユーザー受入テスト
- 利用者マニュアル作成
- パフォーマンステスト
- 負荷テスト
- セキュリティ・リスク評価
- リリースゲート承認
「未完成作業」多いということは、それだけリードタイムが長くなるから、リリースが長期化する原因になる。当然、柔軟なリリースができない。そして、リリースできずに滞留しているインクリメントが多ければ多い程、利用者に使ってもらい収益を得る機会を失っていることにもなる。
「完成の定義」はチームの成熟度により決まる。強い「完成の定義」を実現するためには、チームのケーパビリティを高めていかなくてはならない。「未完成作業」を少しずつスプリント内に取り込んでいき、最終的に「完璧な完成の定義」を実現する。
毎回のスプリントで「完成の定義」を満たしていながら、「未完成作業」があってリリースできないのは状況の透明性を欠いている状態だ。
POのリリース要請に即対応できる「完璧な完成の定義」こそ、本当の「完成の定義」なのである(下記はLeSSサイトより抜粋)。