「完成の定義」と「未完成作業」の関係

スクラムではスプリントを始める前に「完成の定義」を作る。プロダクトバックログアイテムをどこまで作業したら「完成」とするかを定義し、スクラムチーム全員で合意する。

開発チームは、毎回のスプリントで「完成の定義」を満たすようインクリメントを作らなくてはならない。

「完成の定義」には2種類ある

  • 強い「完成の定義」
  • 弱い「完成の定義」

強い「完成の定義」とは、スプリント内でリリースにかかる大半の作業ができることを意味する。リリースまでの「未完成作業」が少ない状態だ。

一方、弱い「完成の定義」とは、スプリント内でリリースまでに必要な作業の大半ができないことを意味する。リリースまで「未完成作業」がたくさん残っている状態だ。

すなわち以下の数式が成り立つ。

  • 「完成の定義」+「未完成作業」=リリースできるインクリメント

そして、即リリースできるインクリメントまでスプリント内で完成できることを「完璧な完成の定義」という。リリースまで未完成作業が皆無の状態だ。

「未完成作業」例:

  • ユーザー受入テスト
  • 利用者マニュアル作成
  • パフォーマンステスト
  • 負荷テスト
  • セキュリティ・リスク評価
  • リリースゲート承認

「未完成作業」多いということは、それだけリードタイムが長くなるから、リリースが長期化する原因になる。当然、柔軟なリリースができない。そして、リリースできずに滞留しているインクリメントが多ければ多い程、利用者に使ってもらい収益を得る機会を失っていることにもなる。

「完成の定義」はチームの成熟度により決まる。強い「完成の定義」を実現するためには、チームのケーパビリティを高めていかなくてはならない。「未完成作業」を少しずつスプリント内に取り込んでいき、最終的に「完璧な完成の定義」を実現する。

毎回のスプリントで「完成の定義」を満たしていながら、「未完成作業」があってリリースできないのは状況の透明性を欠いている状態だ。

POのリリース要請に即対応できる「完璧な完成の定義」こそ、本当の「完成の定義」なのである(下記はLeSSサイトより抜粋)。

Undone Work Causing Risk and Delay