nishida 完成の定義を満たしていないプロダクトバックログアイテムは、スプリントレビューで話題にあげてはいけない？
新井：
スクラムガイドでは「プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない」となっていますから、答えとしてはNGということになりますが…。
とはいえ、やりたくなっちゃうよねという気持ちは分かります。
私が関わっている現場では、プロダクトのタイプや取り組んでいる課題によっても違いますけど、次のスプリントに向けたプランニングの方向性に関わるような場合は、完成の定義を満たしていないプロダクトバックログアイテムでも話題にあげちゃいましょう、とお伝えすることが結構あります。
スクラムガイドには、話題として提示すること自体ダメだよと書かれてはいるんですが…意思決定の結果、そのアイテムが不要ということが分かれば、次のスプリントに持ち越さなくて済みますから、そちらを優先することがありますね。
中村：
スプリントレビューでは、提示したトピックスをもとにステークホルダーと議論をして、次の方向性を決めることが大事なので、そこが満たせるかどうかですよね。
チームやステークホルダーが適切な意思決定をするのに役立ちそうなら、提示してもいいのではないかというスタンスは、いいのではないかと思います。
新井：
ただ、スプリントレビューまでにできなかったという事実や、その背景にあるチームの状況が見えづらくなってしまうこともあるので、それを分かった上でかな。
中村：
できたこととできなかったことを、明確に分けて考えられるといいですね。
例えば、3個のバックログアイテムのうち2個目だけができなかったということであれば、まず1個目と3個目についてデモンストレーションをしたり、ステークホルダーに触ってもらったりして、完成したものに対するフィードバックをもらいます。
2個目については、その後に話をします。この時に、終わらなかった経緯を説明するのではなく、やった中でわかったことなどを話したりします。
あとどうなれば終われるのか、残りがどれくらいあって、どれくらいかかりそうなのかを共有することで、プロダクトオーナーを含めたチームはもちろん、ステークホルダーも状況を理解できます。
そうすると、「そんなに大変なら後に回そうか」とか「ビジネス的にそれほど重要じゃないからカットしよう」というフィードバックをもらえることがあります。
そういう会話をしていけるといいんじゃないでしょうか。
新井：
ステークホルダーとそういう会話ができれば、解像度が高まりますね。
中村：
終わらなかったことを言い訳みたいに話すのではなくて、チームにこういうスキルがあったら、こういう支援があったら、終わったかもしれないというようなことも含めて、ステークホルダーと会話できるといいですね。
この先も似たようなバックログアイテムがある場合は、ステークホルダーにお願いして、特定の技能を持っている人が社内にいるから週に1回サポートしてもらうようにしようか、ということもできるかもしれません。
新井：
スプリントレビューで方針が見えれば、次のスプリントレビューで初めて議論が出るよりもリードタイムが短くて済みます。
その分、早めに問題に着手できるのでいいかなと思います。
中村：
何ができて何ができなかったかが分からないという状況だけは避けたいですね。
Message from coaches
- スプリントレビューでは、ステークホルダーと会話をして次のスプリントの方向性を決めることが大事。チームやステークホルダーが適切な意思決定をするために必要なら、完成の定義を満たしていなくても状況報告として話題にあげてもいい。
- スプリントレビューでは、できたこととできなかったことを明確に分けて考えよう。
- スプリントレビューでは、終わらなかった経緯を話すのではなく、チームとステークホルダーが現状を理解し、次のプランニングに向けた意思決定ができるように状況報告をしよう。足りないスキルや必要な支援についてもステークホルダーに伝えよう。
- スプリントレビューまでにできなかったという事実の裏には、背景となるチームの状況が隠れていることもある。問題から目を背けずに向き合おう。
完成の定義をうまく活用するポイントは？
中村：
スプリントレトロスペクティブの項に、「スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する」と書いてあるんですよね（参照：スクラムガイド）。
要は、完成の定義が自分たちの透明性を上げるのに寄与したか、といったことを見ようということですから、ふりかえりで見ていこうというのが私の考えです。
ふりかえりでは、大抵良かったこととうまくいかなかったことを切り口としてあげると思いますが、完成の定義がきちんと機能したかどうか、完成の定義にアップデートするものがあるか、という点は見落とされがちです。
新井：
日頃の活動の中で完成の定義がマッチしていないと違和感が出てくるはずです。
それをデイリースクラムや、デイリースクラムの後の二次会ででもいいので議論してほしいと思います。
追加の項目がないか、過剰定義ではないか、カバレッジ率はどれくらいが適切なのか、毎回のスプリントレトロスペクティブで話すと時間が足りないかもしれませんが、少なくとも何回かに1回は話題にあげてほしいですね。
参加者コメント：
「完成の定義」は、CIとかCDの仕組みに放り込んでおけるのなら、できるだけそうしておきたいなぁ、と思います。
※CI（Continuous Integration）＝継続的インテグレーション
CD（Continuous Delivery）＝継続的デリバリー／継続的デプロイメント
ソフトウェア開発プロセスの一部で、コードの変更が他の部分に影響を与えていないか、頻繁にコードを統合する仕組み。自動化により効率的にテストを行い、問題を早期に発見・対応することができる。
中村：
一つずつ目視で確認するのは大変なので、自動化するのはとてもいいですね。
割と機械的に判別できると思うので、自動化の対象にしやすいはずです。
新井：
仕組みの中に入れ込めるといいですよね。
参加者コメント：
完成の定義がプロダクトの特性にフィットしていないと、「スプリントすり抜けバグ」が出続けるので、改善していきたいです。
中村：
特に序盤の、プロダクトの特性やバックログアイテムの特徴が分かっていない段階では、完成の定義はスプリントごとにちょっと気づいたらすぐアップデートするくらいの感覚でもいいかもしれません。
Message from coaches
- スプリントレトロスペクティブで、完成の定義がきちんと機能したか、アップデートするものはないか、自分たちの透明性を上げるのに寄与したかどうかを見ていこう。過剰定義になっていないかや、カバレッジ率の検証も大事。
- 毎回のスプリントレトロスペクティブでは難しくても、何回かに1回は検査するようにしよう。デイリースクラムやデイリースクラム後の二次会で話してもOK。
- 完成の定義を満たしているかどうかの検査は、自動化、仕組化するのもおすすめ。
- プロダクトやプロダクトバックログアイテムについてまだよく分からない初期段階では、スプリントごとに気づいた点をアップデートするくらいの感覚でOK。
完成の定義が適用できないプロダクトバックログアイテムの場合はどうすればいい？
中村：
完成の定義って一種類ではないこともあります。
「××機能を追加する」みたいなときのプロダクトバックログアイテムと、「今のユーザーのニーズを知る」みたいな仮説検証のプロダクトバックログアイテムとでは、完成の定義が違うと思うんですよ。
前者ならテストのカバー率が何％か、ステージングにアップされているか、デプロイされているか、コードレビューが済んでいるかみたいなのが完成の定義になります。
一方後者だと、分かったことが何で、次に分かりたいことが何かをレポートにまとめられているとか、そういうのが完成の定義になるはずです。
それぞれに適用できるような完成の定義をつくればいいと思います。
新井：
カテゴリーを分けるのはすごくいい方法ですね。
参加者コメント：
完成の定義とは、チームが対応するすべての種類の仕事に対する完成の定義の総和という理解で良いでしょうか？
中村：
総和というよりは、それぞれにあるよという感じでしょうか。
機能追加のプロダクトバックログアイテムの完成の定義はこのセット、インフラ系のプロダクトバックログアイテムの完成の定義はこのセット、仮説検証のプロダクトバックログアイテムのセットはこれ…みたいなイメージかな。
新井：
ベン図的に重なっている部分もあるでしょうね。
中村：
大事なのは、終わったことがみんなの目に見えるようにしましょうということです。
私はよく「作業が終わったと言える時の完成の定義をつくってみよう」と呼びかけたりしています。
スプリントが終わったと言えるときの完成の定義は何か、リリースが終わったときの完成の定義は何か、と表現することもありますね。
新井：
何をもって終わったと言える？ というところですよね。
言葉の意味にとらわれすぎて本質を見失わないようにしないといけませんね。
中村：
今日はたくさんのコメントをありがとうございました。
新井：
ありがとうございました。
Message from coaches
- 完成の定義は一種類ではない。ソフトウェア開発とインフラ系の開発、仮説検証など、プロダクトバックログアイテムによって完成の定義が違うので、それぞれに適用できる完成の定義をつくっていこう。
- カテゴリーごとに、ベースとなるセットを考えるのもおすすめ。
- 大事なのは、終わったことがみんなの目に見えるようにすること。どうなったら作業が終わったと言えるか、スプリントが終わったと言える時、リリースが終わった時の完成の定義は何かを考えてみよう。
前編はこちら
redjourney.jp次回の「とはいえシリーズ」もお楽しみに。
レッドジャーニー主催イベントはこちらでご案内しています。
