「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」
スクラムにて効果的なスプリントバックログを書き出すには？という話です。スクラムに則っていることを前提とします。
スプリントバックログとはどうあるものか
スプリントバックログ (以下: SBL) は「スプリントに設定された目標1を達成するために必要だとチームが考えている作業の一覧」です。スクラムではこのスプリントに設定された目標を達成するために取り組むプロダクトバックログ (以下: PBL) を選定するので、SBLの大半は「PBL を完了させるために必要な作業」となります。2
ただし応用として、複数のPBLの上流となる作業が生じることもあるし、PBLとは直接関係しない作業もSBLとして扱うこともあります3。単純なPBLとSBLによるツリー構造になるとは限らないことに注意したいです。
有用なSBLを書き出すことで、PBLの完了間際になってチームが慌てふためくことを防いだり、大半のPBLが未完了のままスプリントが終了してしまうリスクを軽減したりできます。これは、PBLが完了するまでの道のりが SBL として明文化されてチームで共有されるためです。これはスクラムの柱のひとつである「透明性」の実現にあたります。
有用なスプリントバックログをどう書き出すか
「完了の定義」と「受け入れ基準」を活用することで、予め抜け漏れが生じづらい有用なスプリントバックログを書き出すことが出来ます。むしろ、後から困ってしまうような「完了の定義」と「受け入れ基準」を運用しているならそれは問題で、改善する必要があると言えるでしょう。
これを上手にやるには「完了の定義」と「受け入れ基準」をそれぞれ理解している必要があります。
完了の定義と受け入れ基準
完了の定義 (Definition of Done = DoD) は、開発者を中心としてチームが主体的に定める「すべてのPBLが完了時に満たすべき事項の一覧」です。インクリメントはどの程度テストされているべきであるかや、開発環境にデプロイするところまでをもって完了とすること、など。完了の定義は、PBLの実装内容に依らず共通するはずです。
受け入れ基準 (Acceptance Criteria = A.C.) は、「PBLがプロダクトオーナーの意図した通りに実現されていることを確認するための手段」です。受け入れ基準はPBLごとに異なります。例えば、「タイトル欄が未入力で送信することができないようにする」というPBLと、「タイトル欄に絵文字を入力できるようにする」というPBLでは、実現する機能や価値が異なるので、PBLが完了とみなされる基準 (= プロダクトオーナーが受け入れる基準) も当然異なります。受け入れ基準は PBL の一部なので、その記述内容はプロダクトオーナーに責任があります。
完了の定義と受け入れ基準からスプリントバックログを導き出す
「PBLを完了させる」とは「完了の定義と受け入れ基準を満たす」ことであり、「PBLを完了させるために必要な作業をSBLとして書き出す」のだから、「完了の定義と受け入れ基準に沿ってSBLを書き出す」ようにすれば、必要な作業の大半を洗い出すことができる はずです。
ここまで来ると、スプリントバックログの表現方法ごとに再現性のある書き出し方法を工夫できます。
- miro などのオンラインホワイトボードツールなら、完了の定義を満たすバックログはコピー&ペーストやテンプレート呼び出しで一気に出せるようにする。
- ホワイトボードの物理カンバンなら、受け入れ基準やその他の PBL は付箋で、完了の定義はマグネットシートで表現する。
- Jira のサブタスクで SBL を表現しているなら、完了の定義に相当する SBL を書き出すオートメーションを実装する。
自動化や型化できるところにマインドシェアを割かず、スプリントごとに異なる要素にクリエイティビティを発揮できるようになると、自ずと成果につながるスクラムの実践ができるんじゃないかと信じています。
