1. スプリントレビュー Deep Dive 2023/1/11 Regional Scrum Gathering Tokyo 2023 初版 株式会社アトラクタ 吉羽 龍太郎

2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー ▸ X(Twitter): @ryuzee / https://www.ryuzee.com/ 2

3. 自己紹介 最新書籍紹介（買ってください!!） 3

4. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり

5. スプリントレビュー DEEP DIVE 5 スプリントレビューとは？ スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することであ る。 スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴール に対する進捗について話し合う。 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成 され、自分たちの環境で何が変化したかについてレビューする。 この情報に基づいて、参加 者は次にやるべきことに協力して取り組む。 新たな機会に見合うようにプロダクトバックロ グを調整することもある。 スプリントレビューはワーキングセッションであり、スクラムチー ムはスプリントレビューをプレゼンテーションだけに限定しないようにする。 -- スクラムガイド2020

6. スプリントレビュー DEEP DIVE スプリントレビューとは？ ▸ スプリントの最後から2番目に行うイベント ▸ プロダクトの検査と適応 6

7. スプリントレビュー DEEP DIVE スプリントレビューの参加者 ▸ スプリントレビューは、スクラムチームとステークホルダーのワーキングセッション ▸ [必須] プロダクトオーナー ▸ [必須] 開発者全員 ▸ [必須] スクラムマスター ▸ [必須] ステークホルダー ▸ ステークホルダーってなんだろう？ 7

8. スプリントレビュー DEEP DIVE ステークホルダーとは？ ▸ プロダクトに対して利害関係を持つ人 ▸ ビジネスステークホルダー: プロダクトを作る上で直接的な関与が必要な人たち ▸ スポンサー： プロダクトを作るための資金やアセットを提供する人たち ▸ 顧客： プロダクトを購入する人たち ▸ エンドユーザー： 実際にプロダクトを使う人たち ▸ …… ▸ スクラムチーム自身もステークホルダー 8

9. スプリントレビュー DEEP DIVE 9 ステークホルダーの分類 ▸ ひとくちにステークホルダーと言っても、影響度やコミュニケーション方法は大きく異なる ▸ スプリントレビューに呼ぶ頻度や時期、参加の必要性も異なる 影響力 大 Market 常に満足させておく必要のあるス テークホルダー（関連する情報だけ を伝達する） 満足させ続ける 緊密にやりとりする Write your 関 心 度 低 常に見ておく必要がほとんどないス テークホルダー（情報共有の間隔を 長くして、最小限の労力で距離を保 つ） 関 心 度 高 定期的に 情報提供する ニーズを予測する 影響力 小 『スクラム実践者が知るべき97のこと』（オライリージャパン）、p.40をもとに作成 緊密に管理する必要のあるステーク ホルダー。グループが大きくなるほ ど、やることも多くなるのは言うまで もないので、人数は最小限にしてお きたい 常に報告する必要のあるステークホ ルダー（前もって計画したり情報を伝 達したりすることで距離を保つ）

10. スプリントレビュー DEEP DIVE 10 スプリントレビューの参加者の例（イメージ） 参加者 スクラムチーム プロダクトマネージャー CEO、VPoP セールス・マーケティング 運用・サポート セキュリティ ユーザー 参加したい人すべて（公開実施） #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 …

11. スプリントレビュー DEEP DIVE スプリントレビューの内容 ▸ スプリントレビューは、スクラムチームとステークホルダーのワーキングセッション ▸ 一方通行のプレゼンテーションにしてはいけない ▸ プロダクトゴールに対する進捗について話し合う ▸ スプリントで達成したことをレビューする ▸ 環境の変化をレビューする ▸ これらの結果、プロダクトバックログを調整することもある 11

12. スプリントレビュー DEEP DIVE デモだけでは不十分 ▸ スプリントレビュー = デモ ではない ▸ デモは1要素に過ぎない ▸ デモに限定すると？ ▸ コンテキスト不足によってフィードバックの質が落ちる ▸ プロダクトに関する幅広い議論や行われない ▸ 結果として、プロダクトバックログの適応の機会が失われる 12

13. スプリントレビュー DEEP DIVE 13 プロダクトゴール プロダクトゴールに対する進捗を話し合う スプリントゴール スプリントゴール スプリントゴール スプリントゴール ▸ プロダクトゴール達成に向けて、このスプリントはどう役に立つのか？ ▸ このままいくとプロダクトゴールは達成できそうか？ ▸ プロダクトゴールが実現するのはいつ頃か？ ▸ プロダクトゴールを達成するために次はどんなことをしようとしているか？

14. スプリントレビュー DEEP DIVE スプリントで達成したことをレビューする ▸ 「やったこと」ではなくて「達成したこと」 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリント で何が達成され、自分たちの環境で何が変化したかについてレビューする。 （略） インクリメントをまとめたものをスプリントレビューで提示する。 それによって、 経験主義がサポートされる。 ただし、スプリント終了前にインクリメントをステ ークホルダーにデリバリーする可能性もある。 スプリントレビューのことを価値 をリリースするための関門と見なすべきではない。（略） -- スクラムガイド2020

15. スプリントレビュー DEEP DIVE なぜインクリメントを提示しなければいけないのか？ ▸ 「包括的なドキュメントよりも動くソフトウェアを」 アジャイルソフトウェア開発宣言 ▸ 「動くソフトウェアこそが進捗の最も重要な尺度です」 アジャイルソフトウェア開発宣言の背後にある原則 ▸ 学習を最大化する ▸ 現物を確認することによって解釈の違いの可能性を排除する ▸ 現物を見ることで、真剣なフィードバックを促す ▸ 価値はスクラムチームの外側で決まる ▸ 中間生成物は市場の観点では価値がない ▸ 進捗報告資料や進捗率では、仮説の検証や評価をしようがない ▸ ほとんどのアイデアは仮説なので、実物で早期に検証するしかない 15

16. スプリントレビュー DEEP DIVE 16 完成していないものは提示しない（そもそもインクリメントでもない） プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースす ることはできない。 ましてやスプリントレビューで提示することもできない。 -- スクラムガイド2020

17. スプリントレビュー DEEP DIVE なぜ未完成のものを提示してはいけないのか？ ▸ ステークホルダーに対して誤った期待を与えてしまう 17 「何も見せないと恥ずかし いし、不安に思うだろうから、作り かけだけど見せておこう」 は悪魔の囁き ▸ 「それ早くリリースしよう」 でも実際はいつリリースできるのかは分からない ▸ 「完成していない」と前置きしても、見たものの方が印象に残る ▸ 透明性の欠如につながる ▸ 「このチームはこのくらいの速度出せるんだね」 でも実際はそんなことはない ▸ 未完成のものを完成させるための作業が見えにくくなる ▸ 完成していないという事実について議論して、ステークホルダーの協力を仰ぐチャンスを失う ▸ 事実に基づかない将来の計画が作られる可能性もある ▸ 結果的に信頼を失うことになる

18. スプリントレビュー DEEP DIVE よくある質問: 「初期のスプリントでインクリメントを見せるの無理……」 ▸ まったく無理ではない ▸ インクリメントを見せられていない理由 ▸ スプリントレビューから逆算して、スプリントプランニングを行っていない ▸ 環境構築、設計、共通化のようなところからやろうとしている ▸ 分業で進めている ▸ 初期のスプリントほど、プロダクトにとって重要そうな箇所を検証したい ▸ 第1スプリントから意味のあるインクリメントを提示することを前提にする ▸ 早期にインクリメントを提示することは、ステークホルダーとの信頼関係の形成にも役立つ 18

19. スプリントレビュー DEEP DIVE 19 環境の変化をレビューする ▸ どんなフィードバックをするべきか、今後の予定やPBIの順番の意図が分かる スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリント で何が達成され、自分たちの環境で何が変化したかについてレビューする。 （略） インクリメントをまとめたものをスプリントレビューで提示する。 それによって、 経験主義がサポートされる。 ただし、スプリント終了前にインクリメントをステ ークホルダーにデリバリーする可能性もある。 スプリントレビューのことを価値 をリリースするための関門と見なすべきではない。（略） -- スクラムガイド2020

20. スプリントレビュー DEEP DIVE ここまでの内容を踏まえたスプリントレビューのアジェンダの例 ▸ チェックイン、目的の共有 ▸ プロダクトやスプリントの概要の共有 ▸ スプリント中の状況の変化などの共有と議論 ▸ インクリメントのデモとフィードバック、Q&A ▸ 今後の見通しや直近のスプリントの予定の共有と議論 ▸ まとめ ▸ あくまで例であり、すべてのスプリントレビューで同じにする必要もなく、順番も変えてよい 20

21. スプリントレビュー DEEP DIVE 1. チェックイン、目的の共有 ▸ さまざまな人が参加することがあるので、自己紹介する ▸ 名前、所属、プロダクトへの関わり…… ▸ ワーキングアグリーメントを共有する（PCやスマホの利用、発言の仕方などなど） ▸ スプリントレビューの目的を共有する ▸ 参加者のなかにはスクラムに詳しくない人や、従来型の考えに慣れている人がいるかもしれない ▸ 説明不足のままだと誤解を招く可能性 ▸ 「まだ全然機能が足りない！なぜ不十分なものを見せるんだ？」 ▸ 「前回フィードバックしたことがなぜ今回反映されていないんだ？」 ▸ 「ここで承認すればいいんだな？」 21

22. スプリントレビュー DEEP DIVE 2. プロダクトやスプリントの概要の共有 ▸ プロダクトゴールの紹介 ▸ プロダクトゴールそのものは繰り返し伝えるとよい ▸ プロダクトゴールの達成に向けて、今どこにいるのか ▸ スプリントゴールの紹介 22

23. スプリントレビュー DEEP DIVE 3. スプリント中の環境の変化などの共有と議論 ▸ プロダクトそのものの状況 ▸ 直近リリースした機能の利用状況 ▸ 障害や割り込み ▸ マーケットの変化 ▸ 競合の特筆すべき動き ▸ セールスパイプラインの状況 ▸ 新規顧客の状況 ▸ …… ▸ プロダクトをとりまく状況のうち、この場で取り上げることが有意義と思えることはなんでもよい 23

24. スプリントレビュー DEEP DIVE 24 4. インクリメントのデモとフィードバック、Q&A ▸ 今スプリントで選択したプロダクトバックログアイテムの紹介 ▸ 完成したもの ▸ 完成しなかったもの ▸ すべてのプロダクトバックログアイテムをデモしなくてもよい ▸ 大きな価値を持つもの、フィードバックが必要なもの、参加者の関心が高いものは確実にカバーする ▸ 運用関連のもの、バグフィックスなどは必要ない

25. スプリントレビュー DEEP DIVE 25 デモのやり方はさまざま ▸ 一方的に発表しなければいけないわけではない ▸ 参加者が自由に触れるようにしておき、その様子を観察するのも良い手 スクラムチームによる発表 参加者による操作

26. スプリントレビュー DEEP DIVE フィードバックのやり方はさまざま ▸ 口頭で発言する ▸ スクラムチームはやりとりのメモを残しておく ▸ 参加者の間でパワーバランスが微妙な場合に、遠慮したり警戒したりして発言が偏る可能性 ^1 ▸ SlackやTeamsなどのオンラインツールで、発言者が分かる形で投稿する ▸ 多量のフィードバックが得られ、記録の手間が省ける ▸ 付箋や匿名チャット、アンケートツールなどで、発言者が分からない形で投稿する ▸ 上記に加えて、フィードバックの重み付けにバイアスがかかりにくい点がメリット ▸ 議論は必要なので、すべてをツールに置き換えることはできない [^1] それ自体は組織的な障害かもしれないので対処は必要 26

27. スプリントレビュー DEEP DIVE ステークホルダーへの質問の例 ▸ インクリメントはユーザーの課題を解決しそうか？ ▸ いちばん気に入った箇所と、いちばん気に入らなかった箇所はなにか？ ▸ 機能の間違いはないか？ ▸ 機能不足、過剰な機能があるか？ ▸ 見た目の調整が必要か？ ▸ スプリントゴールは本当に達成できていると思うか？ ▸ プロダクトを成功させるために変えたらよいことがあるか？ ▸ プロダクトビジョンやプロダクトゴールは同じままでよいか？ ▸ そう思うのはなぜか？ 27

28. スプリントレビュー DEEP DIVE 28 フィードバックの扱い方 ▸ フィードバックしてくれたことに感謝を示す ▸ ネガティブフィードバックも重要なフィードバック ▸ フィードバックは記録しておき分析や選別を行う ▸ フィードバックにすぐ取り組まなければいけないわけではない ▸ プロダクトバックログの全体性を考える ▸ 「次のスプリントで対応します！」「すぐやります！」は危険な兆候 ▸ 明らかに次のスプリントのスプリントゴールやプロダクトバックログアイテムに影響がありそうな場合 ▸ スプリントレビュー終了後にすぐにリファインメントを行うこともある

29. スプリントレビュー DEEP DIVE 5. 今後の見通しや直近のスプリントの予定の共有と議論 29

30. スプリントレビュー DEEP DIVE 7. まとめ 30

31. スプリントレビュー DEEP DIVE （8. お祝いをする） 31

32. スプリントレビュー DEEP DIVE スプリントレビューの事前準備 ▸ スプリントレビューで扱う内容を踏まえると事前準備が必要 ▸ ワーキングセッションなどで過度な準備は不要 ▸ でも準備不足だと期待した効果が得られず、参加者の時間をムダにしてしまう ▸ 今後は参加しなくていいやと思われたら負け ▸ どのくらいの準備をするとよいかも検査と適応 32

33. スプリントレビュー DEEP DIVE スプリントレビューの事前準備の例 ▸ ステークホルダーに招待を送る ▸ スプリントゴールを達成できているかどうかを確認する ▸ プロダクトゴールの達成に向けて今どんな状況なのかを説明できるようにする ▸ 個々のプロダクトバックログアイテムが完成しているかどうかの確認する ▸ スプリントレビューでのデモ手順やシナリオを確認する ▸ プロダクトバックログが最新化されていることを確認する ▸ （必要であれば）プレゼンテーションなどの簡単な説明資料を準備する ▸ … ▸ これだけに限らない。「検査と適応」していく 33

34. スプリントレビュー DEEP DIVE スプリントレビューのアンチパターン ▸ スプリントレビューをキャンセルする ▸ 事前準備をしていない ▸ プロダクトオーナーがステークホルダーを招集していない ▸ スライドやスクリーンショットでデモをしている ▸ 完成していないものをデモしている ▸ 完成したものと完成していないものをスプリントレビューで識別している ▸ 雑なデモデータを使っている ▸ スプリントレビューが進捗確認会議になっている ▸ スプリントレビューがステークホルダーの承認イベントになっている ▸ 最新の情報を使って今後の見通しなどの話し合いをしていない ▸ 得られたフィードバックを記録しない 34

35. スプリントレビュー DEEP DIVE 35 スプリントレビューの鉄則 ▸ なにはともあれインクリメントを見せろ ▸ スプリントレビューのやり方を改善しろ ▸ フィードバックを得られるインクリメントを用意しろ ▸ スプリントレビュー直前にインクリメントを変更するな ▸ スプリントレビューから逆算してスプリントプランニン グしろ ▸ プロダクトの状況や進捗を表す簡単な資料を用意しろ ▸ スプリントレビューの会話のメモを取っておけ ▸ デモはプロダクトオーナーと開発者全員ができるよう にしておけ ▸ スプリントレビューで「次のスプリントで対応する」とか コミットするな ▸ スクラムチームの外側のステークホルダーを呼べ ▸ そのスプリントで何も完成しなくても、スプリントレ ビューをスキップするな ▸ スプリントゴールに応じて、どのステークホルダーを呼 ぶかを選べ ▸ スクラムチーム全員が参加しろ ▸ とはいえ、とにもかくにもインクリメントを提示できるよ うにしろ