1. スプリントレビュー Deep Dive 2023/1/11 Regional Scrum Gathering Tokyo 2023 株式会社アトラクタ 吉羽 龍太郎
2. 自己紹介 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
3. スプリントレビュー DEEP DIVE 3 ありがちな光景 念入りに時間をかけて完璧なスプ リントプランニングができた！ これで今回こそ勝てる！ またもや全然計画通りにいかな かった。途中のものを見せるかレ ビューをキャンセルするかなぁ……
4. スプリントレビュー DEEP DIVE 4 ありがちな光景 念入りに時間をかけて完璧なスプ リントプランニングができた！ これで今回こそ勝てる！ またもや全然計画通りにいかな かった。途中のものを見せるかレ ビューをキャンセルするかなぁ…… これって非常にまずいですよね？ スプリントレビューの捉え方に問題がありそうです
5. スプリントレビュー DEEP DIVE 5 ありがちな光景 念入りに時間をかけて完璧なスプ リントプランニングができた！ これで今回こそ勝てる！ またもや全然計画通りにいかな かった。途中のものを見せるかレ ビューをキャンセルするかなぁ…… スプリントレビューについて詳しくみていきましょう！
6. スプリントレビュー DEEP DIVE 2020年版のスクラムガイドは407文字（2017年版は990文字。当社調べ） Howが削ぎ落とされ、イメージがつきにくくなった？ 6
7. スプリントレビュー DEEP DIVE 7 スプリントレビューとは？ スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することであ る。 スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴール に対する進捗について話し合う。 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成 され、自分たちの環境で何が変化したかについてレビューする。 この情報に基づいて、参加 者は次にやるべきことに協力して取り組む。 新たな機会に見合うようにプロダクトバックロ グを調整することもある。 スプリントレビューはワーキングセッションであり、スクラムチー ムはスプリントレビューをプレゼンテーションだけに限定しないようにする。 -- スクラムガイド2020
8. スプリントレビュー DEEP DIVE スプリントレビューとは？ ▸ プロダクトの検査と適応を行うためのイベント ▸ スプリントレトロスペクティブはプロセスの検査と適応 ▸ 検査と適応を意味あるものにするためには？ ▸ 透明性が重要 8
9. スプリントレビュー DEEP DIVE スプリントレビューの参加者 ▸ スプリントレビューは、スクラムチームとステークホルダーのワーキングセッション ▸ [必須] プロダクトオーナー ▸ [必須] 開発者全員 ▸ [必須] スクラムマスター ▸ [必須] ステークホルダー ▸ ステークホルダーってなんだろう？ 9
10. スプリントレビュー DEEP DIVE ステークホルダーとは？ ▸ プロダクトに対して利害関係を持つ人 ▸ ビジネスステークホルダー: プロダクトを作る上で直接的な関与が必要な人たち ▸ スポンサー： プロダクトを作るための資金やアセットを提供する人たち ▸ 顧客： プロダクトを購入する人たち ▸ エンドユーザー： 実際にプロダクトを使う人たち ▸ …… ▸ スクラムチーム自身もステークホルダー 10
11. スプリントレビュー DEEP DIVE 11 ステークホルダーの分類 ▸ ひとくちにステークホルダーと言っても、影響度やコミュニケーション方法は大きく異なる ▸ スプリントレビューに呼ぶ頻度や時期、参加の必要性も異なる 影響力 大 Market 常に満足させておく必要のあるス テークホルダー（関連する情報だけ を伝達する） 満足させ続ける 緊密にやりとりする Write your 関 心 度 低 常に見ておく必要がほとんどないス テークホルダー（情報共有の間隔を 長くして、最小限の労力で距離を保 つ） 関 心 度 高 定期的に 情報提供する ニーズを予測する 影響力 小 『スクラム実践者が知るべき97のこと』（オライリージャパン）、p.40、ウィレム・ベルマーク、ロビン・スフールマンをもとに作成 緊密に管理する必要のあるステーク ホルダー。グループが大きくなるほ ど、やることも多くなるのは言うまで もないので、人数は最小限にしてお きたい 常に報告する必要のあるステークホ ルダー（前もって計画したり情報を伝 達したりすることで距離を保つ）
12. スプリントレビュー DEEP DIVE 12 スプリントレビューの参加者の例（イメージ） 参加者 スクラムチーム プロダクトマネージャー CEO、VPoP セールス・マーケティング 運用・サポート セキュリティ プロダクトの実際の利用者 参加したい人すべて（公開実施） #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 …
13. スプリントレビュー DEEP DIVE 13 ステークホルダー招待のコツ ▸ スプリントプランニングの時点で、誰を呼ぶと良いかを検討する ▸ 予定は先に押さえておく（カレンダーの招待を送る） ▸ 不要になったらキャンセルするだけ ▸ 適切なスプリントゴールが設定できれば、誰を呼ぶとよいかがわかりやすくなる ▸ スプリントゴールは、招待を送るときの案内文のタイトルになる ▸ スプリントゴールが「ID #893、#894、#895、#896の完成」みたいなのではステークホルダーは理 解できないし、関心も持てない
14. スプリントレビュー DEEP DIVE スプリントレビューでのスクラムチームの役割 ▸ スクラムガイド(2020)では、スプリントレビューにおけるスクラムチームの役割にほぼ言及していない ▸ プロダクトオーナー ▸ プロダクトオーナーはプロダクトに責任を持ち、プロダクトゴールやスプリントゴールを最終決定する ▸ スプリントレビューの場ではプロダクトの状況を共有・議論する ▸ これを踏まえれば、プロダクトオーナーがスプリントレビューをリードするのが自然 ▸ プロダクトオーナーはレビューワーではない ▸ スクラムマスター ▸ 確実にイベントが開催されるようにし、必要ならファシリテーションする ▸ デモや個々の説明は誰がやっても構わない ▸ スクラムチームとして最大の成果を出せるように、お互いに協力する 14
15. スプリントレビュー DEEP DIVE スプリントレビューの内容 ▸ スプリントレビューは、スクラムチームとステークホルダーのワーキングセッション ▸ 一方通行のプレゼンテーションにしてはいけない ▸ プロダクトゴールに対する進捗について話し合う ▸ スプリントで達成したことをレビューする ▸ 環境の変化をレビューする ▸ これらの結果、プロダクトバックログを調整することもある（注意が必要） 15
16. スプリントレビュー DEEP DIVE デモだけでは不十分 ▸ スプリントレビュー = デモ ではない ▸ デモは1要素に過ぎない ▸ デモに限定すると？ ▸ コンテキスト不足によってフィードバックの質が落ちる ▸ プロダクトに関する幅広い議論や行われない ▸ 結果として、プロダクトバックログの適応の機会が失われる 16
17. スプリントレビュー DEEP DIVE 17 プロダクトゴール プロダクトゴールに対する進捗を話し合う スプリントゴール スプリントゴール スプリントゴール スプリントゴール ▸ プロダクトゴール達成に向けて、このスプリントはどう役に立つのか？ ▸ このままいくとプロダクトゴールは達成できそうか？ ▸ プロダクトゴールが実現するのはいつ頃か？ ▸ プロダクトゴールを達成するために次はどんなことをしようとしているか？
18. スプリントレビュー DEEP DIVE 18 スプリントで達成したことをレビューする ▸ 「やったこと」ではなくて「達成したこと」 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリント で何が達成され、自分たちの環境で何が変化したかについてレビューする。 （略） インクリメントをまとめたものをスプリントレビューで提示する。 それによって、 経験主義がサポートされる。 ただし、スプリント終了前にインクリメントをステ ークホルダーにデリバリーする可能性もある。 スプリントレビューのことを価値 をリリースするための関門と見なすべきではない。（略） -- スクラムガイド2020
19. スプリントレビュー DEEP DIVE なぜインクリメントを提示しなければいけないのか？ ▸ 「包括的なドキュメントよりも動くソフトウェアを」 アジャイルソフトウェア開発宣言 ▸ 「動くソフトウェアこそが進捗の最も重要な尺度です」 アジャイルソフトウェア開発宣言の背後にある原則 ▸ 学習を最大化する ▸ 現物を確認することによって解釈の違いの可能性を排除する ▸ 現物を見ることで、真剣なフィードバックを促す ▸ 価値はスクラムチームの外側で決まる ▸ 中間生成物は市場の観点では価値がない ▸ 進捗報告資料や進捗率では、仮説の検証や評価をしようがない ▸ ほとんどのアイデアは仮説なので、実物で早期に検証するしかない 19
20. スプリントレビュー DEEP DIVE 20 完成していないものは提示しない（そもそもインクリメントでもない） プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースす ることはできない。 ましてやスプリントレビューで提示することもできない。 -- スクラムガイド2020
21. スプリントレビュー DEEP DIVE なぜ未完成のものを提示してはいけないのか？ ▸ ステークホルダーに対して誤った期待を与えてしまう 21 「何も見せないと恥ずかし いし、不安に思うだろうから、作り かけだけど見せておこう」 は悪魔の囁き ▸ 「それ早くリリースしよう」 でも実際はいつリリースできるのかは分からない ▸ 「完成していない」と前置きしても、見たものの方が印象に残る ▸ 透明性の欠如につながる ▸ 「このチームはこのくらいの速度出せるんだね」 でも実際はそんなことはない ▸ 未完成のものを完成させるための作業が見えにくくなる ▸ 完成していないという事実について議論して、ステークホルダーの協力を仰ぐチャンスを失う ▸ 事実に基づかない将来の計画が作られる可能性もある ▸ 結果的に信頼が失われる
22. スプリントレビュー DEEP DIVE 22 よくある質問: 「インクリメントがないのでレビューをスキップしていいですか？」 ▸ ダメです ▸ ステークホルダーに色々言われたら嫌だという気持ちは分かる ▸ だが、デモは一要素に過ぎない （インクリメントがないというデモをする手もある） ▸ プロダクトゴールに対する進捗を話し合う ▸ 環境の変化を話し合う（後述） ▸ 「インクリメントが何もない」ということ自体がニュース ▸ これによって何か影響があるかもしれない ▸ 組織の協力を仰いで解決しなければいけないかもしれない ▸ スキップしたら学習の機会を失うことになる
23. スプリントレビュー DEEP DIVE よくある質問: 「初期のスプリントでインクリメントを見せるの無理……」 ▸ まったく無理ではない ▸ インクリメントを見せられていない理由 ▸ スプリントレビューから逆算して、スプリントプランニングを行っていない ▸ 環境構築、設計、共通化のようなところからやろうとしている ▸ 分業で進めている ▸ 見せるのを怖がっている ▸ 初期のスプリントほど、プロダクトにとって重要そうな箇所を検証したい ▸ 第1スプリントから意味のあるインクリメントを提示することを前提にする ▸ 早期にインクリメントを提示することは、ステークホルダーとの信頼関係の形成にも役立つ 23
24. スプリントレビュー DEEP DIVE 24 環境の変化をレビューする ▸ どんなフィードバックをするべきか、今後の予定やPBIの順番の意図が分かる スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリント で何が達成され、自分たちの環境で何が変化したかについてレビューする。 （略） インクリメントをまとめたものをスプリントレビューで提示する。 それによって、 経験主義がサポートされる。 ただし、スプリント終了前にインクリメントをステ ークホルダーにデリバリーする可能性もある。 スプリントレビューのことを価値 をリリースするための関門と見なすべきではない。（略） -- スクラムガイド2020
25. スプリントレビュー DEEP DIVE 25 スプリントレビューのタイムボックス ▸ 1週間スプリントなら1時間、2週間スプリントなら2時間くらいに設定するのが普通 スプリントレビューは、スプリントの最後から2番目のイベントであり、スプリント が1か月の場合、タイムボックスは最大4時間である。 スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。 -- スクラムガイド2020
26. スプリントレビュー DEEP DIVE ここまでの内容を踏まえたスプリントレビューのアジェンダの例 ▸ 1. チェックイン、目的の共有 ▸ 2. プロダクトとプロダクトゴールの紹介 ▸ 3. プロダクトを取り巻く状況の共有と議論 ▸ 4. スプリントの概要の共有 ▸ 5. インクリメントのデモとフィードバック、Q&A ▸ 6. 今後の見通しや直近のスプリントの予定の共有と議論 ▸ 7. まとめ ▸ あくまで例であり、すべてのスプリントレビューで同じにする必要もなく、順番も変えてよい 26
27. スプリントレビュー DEEP DIVE 1. チェックイン、目的の共有 ▸ さまざまな人が参加することがあるので、自己紹介する ▸ 名前、所属、プロダクトへの関わり…… ▸ 行動規範を共有する（PCやスマホの利用、発言の仕方などなど） ▸ スプリントレビューの目的を共有する ▸ 参加者のなかにはスクラムに詳しくない人や、従来型の考えに慣れている人がいるかもしれない ▸ 説明不足のままだと誤解を招く可能性 ▸ 「まだ全然機能が足りない！なぜ不十分なものを見せるんだ？」 ▸ 「前回フィードバックしたことがなぜ今回反映されていないんだ？」 ▸ 「ここで承認すればいいんだな？」 27
28. スプリントレビュー DEEP DIVE 2. プロダクトとプロダクトゴールの紹介 ▸ プロダクトそのものの紹介 ▸ プロダクトビジョン ▸ 誰向けのどんなプロダクトなのか ▸ プロダクトゴールの紹介 ▸ プロダクトゴールは有期で計測可能なもの ▸ プロダクトゴールの達成に向けて、今どこにいるのか ▸ プロダクトビジョンやプロダクトゴールは繰り返し何度でも伝えたほうがよい ▸ みんなで同じ方向に向かうためには、大事なことは何度でも ▸ 初参加の人がいることもある 28
29. スプリントレビュー DEEP DIVE 3. プロダクトを取り巻く状況の共有 ▸ プロダクトそのものの状況 ▸ 直近リリースした機能の利用状況 ▸ マーケットの変化 ▸ 競合の特筆すべき動き ▸ セールスパイプラインの状況 ▸ 新規顧客の状況 ▸ …… ▸ プロダクトをとりまく状況のうち、この場で取り上げることが有意義と思えることはなんでもよい 29
30. スプリントレビュー DEEP DIVE 4. スプリントの概要の共有 ▸ スプリントゴールの紹介 ▸ 今スプリントで選択したプロダクトバックログアイテムの紹介 ▸ 完成したもの ▸ 完成しなかったもの ▸ 障害や割り込み、想定外の事象の共有 30
31. スプリントレビュー DEEP DIVE 31 5. インクリメントのデモとフィードバック、Q&A ▸ スプリントで完成したプロダクトバックログアイテムのすべてをデモする必要はない ▸ 大きな価値を持つもの、フィードバックが必要なもの、参加者の関心が高いものは確実にカバーする ▸ 運用関連のもの、バグフィックスなどは必要ない
32. スプリントレビュー DEEP DIVE 32 デモのやり方はさまざま ▸ 一方的に発表しなければいけないわけではない ▸ 参加者が自由に触れるようにしておき、その様子を観察するのも良い手 スクラムチームによる発表 参加者による操作
33. スプリントレビュー DEEP DIVE デモに使うデータに関心を払う ▸ 雑なデータを使うと、それに応じてフィードバックの質が下がる ▸ 先にリリースして、スプリントレビューで本番環境をデモすることもある 33
34. スプリントレビュー DEEP DIVE デモの直前にインクリメントをあわてて変更しない（ほうがいい） ▸ ギリギリになって問題を見つけることもある ▸ 今なら間に合いそうだと判断して修正したくなる（気持ちはわかる） ▸ 結果の事例 ▸ 実際に変更したら、スプリントレビューですべてが500 Internal Server Errorになった ▸ テストが通らなくなったが、そのままデモした ▸ 実は直す前が正しかった ▸ 焦るとロクなことがないし、準備を無にする可能性もある ▸ 十分に安全装置を用意してから 34
35. スプリントレビュー DEEP DIVE フィードバックのやり方もさまざま ▸ 口頭で発言する ▸ スクラムチームはやりとりのメモを残しておく ▸ 参加者の間でパワーバランスが微妙な場合に、遠慮したり警戒したりして発言が偏る可能性 ^1 ▸ SlackやTeamsなどのオンラインツールで、発言者が分かる形で投稿する ▸ 多量のフィードバックが得られ、記録の手間が省ける ▸ 付箋や匿名チャット、アンケートツールなどで、発言者が分からない形で投稿する ▸ 上記に加えて、フィードバックの重み付けにバイアスがかかりにくい点がメリット ▸ 議論は必要なので、すべてをツールに置き換えることはできない [^1] それ自体は組織的な障害かもしれないので対処は必要 35
36. スプリントレビュー DEEP DIVE ステークホルダーへの質問の例 ▸ インクリメントはユーザーの課題を解決しそうか？ ▸ いちばん気に入った箇所と、いちばん気に入らなかった箇所はなにか？ ▸ 機能の間違いはないか？ ▸ 機能不足、過剰な機能があるか？ ▸ 見た目の調整が必要か？ ▸ スプリントゴールは本当に達成できていると思うか？ ▸ プロダクトを成功させるために変えたらよいことがあるか？ ▸ プロダクトビジョンやプロダクトゴールは同じままでよいか？ ▸ そう思うのはなぜか？ 36
37. スプリントレビュー DEEP DIVE 37 フィードバックの扱い方 ▸ フィードバックしてくれたことに感謝を示す ▸ ネガティブフィードバックも重要なフィードバック ▸ フィードバックは記録しておき分析や選別を行う ▸ フィードバックにすぐ取り組まなければいけないわけではない ▸ プロダクトバックログの全体性を考える ▸ 「次のスプリントで対応します！」「すぐやります！」は危険な兆候 ▸ 明らかに次のスプリントのスプリントゴールやプロダクトバックログアイテムに影響がありそうな場合 ▸ スプリントレビュー終了後にすぐにリファインメントを行うこともある
38. スプリントレビュー DEEP DIVE 6. 今後の見通しや直近のスプリントの予定の共有と議論 ▸ プロダクトゴール達成の見通し ▸ プロダクトバックログに残っているアイテムの概要 ▸ 次回リリーススケジュールの見通し ▸ 直近のスプリントで取り組もうとしていること ▸ 予算 ▸ 次回予告 ▸ これらを変更する必要がありそうか、どう変更するとよさそうか ▸ 必要に応じてプロダクトバックログを更新することもある（その場でやるのはあまり推奨しない） 38
39. スプリントレビュー DEEP DIVE 7. まとめ ▸ 議論の内容のサマリー ▸ スクラムチームに影響がありそうなことを中心にする ▸ 次回のスプリントレビュー予定 ▸ 今回のスプリントレビューがどうだったかを簡単にふりかえる 39
40. スプリントレビュー DEEP DIVE （8. お祝いをする） ▸ プロダクトゴールを達成したり、大きな成果を上げたときにはお祝いするのもよい ▸ （業務時間内で全員が参加できるタイミングがベター） 40
41. スプリントレビュー DEEP DIVE （参考） アジェンダの雛形はあちこちで公開されているので参考にしよう 出典: https://agility.im/frequent-agile-question/the-sprint-review-canvas-explained/ 41
42. スプリントレビュー DEEP DIVE スプリントレビューの事前準備 ▸ スプリントレビューで扱う内容を踏まえると事前準備が必要 ▸ ワーキングセッションなので過度な準備は不要 ▸ でも準備不足だと期待した効果が得られず、参加者の時間をムダにしてしまう ▸ 今後は参加しなくていいやと思われたら負け ▸ どのくらいの準備をするとよいかも検査と適応 42
43. スプリントレビュー DEEP DIVE スプリントレビューの事前準備の例 ▸ ステークホルダーに招待を送る ▸ スプリントゴールを達成できているかどうかを確認する ▸ プロダクトゴールの達成に向けて今どんな状況なのかを説明できるようにする ▸ 個々のプロダクトバックログアイテムが完成しているかどうかの確認する ▸ スプリントレビューでのデモ手順やシナリオを確認する ▸ プロダクトバックログが最新化されていることを確認する ▸ （必要であれば）プレゼンテーションなどの簡単な説明資料を準備する ▸ … ▸ これだけに限らない。「検査と適応」していく 43
44. スプリントレビュー DEEP DIVE 44 スプリントレビューのアンチパターン ▸ スプリントレビューをキャンセルする ▸ 事前準備をしていない ▸ スプリントレビューが進捗確認会議になってい る ▸ プロダクトオーナーがステークホルダーを招集 していない ▸ スプリントレビューがステークホルダーの承認 イベントになっている ▸ スライドやスクリーンショットでデモをしている ▸ 最新の情報を使って今後の見通しなどの話し 合いをしていない ▸ 完成していないものをデモしている ▸ 完成したものと完成していないものをスプリン トレビューで識別している ▸ 雑なデモデータを使っている ▸ 得られたフィードバックを記録しない
45. スプリントレビュー DEEP DIVE 45 スプリントレビューの鉄則 ▸ なにはともあれインクリメントを見せろ ▸ スプリントレビューのやり方を改善しろ ▸ フィードバックを得られるインクリメントを用意しろ ▸ スプリントレビュー直前にインクリメントを変更するな ▸ スプリントレビューから逆算してスプリントプランニン グしろ ▸ プロダクトの状況や進捗を表す簡単な資料を用意しろ ▸ スプリントレビューの会話のメモを取っておけ ▸ デモはプロダクトオーナーと開発者全員ができるよう にしておけ ▸ スプリントレビューで「次のスプリントで対応する」とか コミットするな ▸ スクラムチームの外側のステークホルダーを呼べ ▸ そのスプリントで何も完成しなくても、スプリントレ ビューをスキップするな ▸ スプリントゴールに応じて、どのステークホルダーを呼 ぶかを選べ ▸ スクラムチーム全員が参加しろ ▸ とはいえ、とにもかくにもインクリメントを提示できるよ うにしろ
46. スプリントレビュー DEEP DIVE よい計画を作ろうとするより よいスプリントレビューになるようにしよう 46
