1. スプリントプランニング Deep Dive 2022/8/27 Scrum Fest Sendai 2022 株式会社アトラクタ 吉羽 龍太郎
2. 自己紹介 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. 自己紹介 新刊紹介 (2022/8/26発売) 本書は、エンジニアリングチームのマネジメントの仕事全般を紹介し、 エンジニアリングマネージャーに必要な考え方やスキルを解説します。 はじめに、自分の役割と組織のさまざまな部分がどう関係するかを理 解し、習慣を整えることで自分自身を管理することを学びます。そして、 日々のマネジメント業務で必要なツールとプロセスを紹介し、スタッフ との関係性の構築、モチベーションの理解、評価や採用などを解説しま す。さらに社内政治や難しい状況での判断、その後のキャリアについて 説明します。 マネジメントのさまざまな段階に沿って、日々の仕事に取り入れられる 実践的なアドバイスを紹介する本書は、エンジニアリングチームのマ ネージャーに必携の一冊です。 4
5. スプリントプランニング DEEP DIVE 5 “ 計画それ自体に価値はないが、 立案はすべてに勝る ” ドワイト・D・アイゼンハワー 第34代アメリカ大統領 Source:https://en.wikipedia.org/wiki/Dwight_D._Eisenhower
6. スプリントプランニング DEEP DIVE 6 スプリントプランニングとは？ スプリントプランニングはスプリントの起点であり、ここではスプリントで実行す る作業の計画を立てる。 結果としてできる計画は、スクラムチーム全体の共同 作業によって作成される。 (中略) スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプラ ンニングに招待してもよい。 -- スクラムガイド2020
7. スプリントプランニング DEEP DIVE スプリントプランニングとは？ ▸ スプリントの冒頭で行う計画づくり ▸ スプリントの起点になる 7
8. スプリントプランニング DEEP DIVE スプリントプランニングの参加者 ▸ スプリントプランニングは、スクラムチームの共同作業 ▸ [必須] プロダクトオーナー ▸ [必須] 開発者全員 ▸ [必須] スクラムマスター ▸ 必要な場合は外部の関係者を呼んでもよい 8
9. スプリントプランニング DEEP DIVE 9 スプリントプランニング プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテ ムと、それらとプロダクトゴールとの関連性について話し合う準備ができている かを確認する。 -- スクラムガイド2020 「確認する」って どういうことだろう？
10. スプリントプランニング DEEP DIVE 10 スプリントプランニング The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal -- スクラムガイド2020（英語版） 〔～を〕確かにする、保証す る、請け合う、確保する
11. スプリントプランニング DEEP DIVE 11 つまり？ ▸ = 「プロダクトオーナーは、参加者が最も重要なプロダクトバックログアイテムと、それらとプロダクト ゴールとの関連性について話し合う準備が、確実にできているようにする」 ▸ 以下のような準備が必要になる ▸ プロダクトバックログが最新化されている ▸ 参加者が内容をある程度理解している ▸ 会話に必要な準備ができている ▸ = 十分リファインメントできている
12. スプリントプランニング DEEP DIVE 12 トピック1：このスプリントはなぜ価値があるのか？ プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのよ うに高めることができるかを提案する。 次に、スクラムチーム全体が協力して、 そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴ ールを定義する。 スプリントゴールは、スプリントプランニングの終了までに確 定する必要がある。 -- スクラムガイド2020
13. スプリントプランニング DEEP DIVE スプリントゴールとは ▸ スプリントの目的や達成したいことを簡単にまとめたもの ▸ スプリントゴールはスプリントの唯一の目的 ▸ つまり選択したプロダクトバックログアイテムをすべて完成させることは目的ではない ▸ ステークホルダーに伝える。つまりステークホルダーが理解できるものでなければいけない ▸ スプリントプランニングの終了までに確定する 13
14. スプリントプランニング DEEP DIVE 14 なぜスプリントゴールが必要か ▸ スプリント中に集中すべきことが明確になり、スクラムチーム内外の協力が得やすくなる ▸ ゴールの達成に向けて柔軟性が生まれる（アウトカム＞アウトプット） ▸ ゴールを踏まえてプロダクトバックログアイテムを明確に並べられるようになる ▸ スプリントレビューに誰を呼べばよいかわかりやすくなり、適切なフィードバックが得られるようになる ▸ スプリントの意味がわかりやすくなり、今何をやっているかステークホルダーに伝えやすくなる ▸ 前スプリントとの差分が、明確に意味を持つ状態になり、リリースするかどうかの判断がしやすくなる
15. スプリントプランニング DEEP DIVE スプリントゴールの例（改善の余地のある例） 改善の余地のある例 ショッピングカートの機能を強化する 性能を改善する Tシャツ販売に対応する ログインの改善 バグ修正 プロトタイプを作る デザイン変更 効果測定対応 15
16. スプリントプランニング DEEP DIVE スプリントゴールの例（達成できたかを評価しやすい例） 達成できたかを評価しやすい例 コンバージョンレートを増加するために、購入に必要なステップ数を減らす ページの読み込み時間を2秒以内にする Tシャツをサイズ別に販売できるようにする 古いログイン画面のデザインを見直し、ログイン操作の誤操作回数を30%削減 重大バグと分類されている項目を解消する 登録機能のUXをユーザーテストで確認できるようにする デザイン変更 (1) 主要導線部分を新デザインに変更し評価可能にする プロダクトバックログアイテムごとの価値を計測できるようにGAを設定する 16
17. スプリントプランニング DEEP DIVE スプリントゴールはスプリント中は不変 ▸ スプリントゴールはスプリント中は不変 ▸ スプリントゴールを犠牲にしても優先しなければいけないゴールが登場した場合は、スプリントを キャンセルする ▸ スプリントゴールをスプリント中に変えると？ ▸ 多くのムダを生み出す（仕掛り中を途中で放置するなど） ▸ 作業内容が増え、チームが危険にさらされる ▸ そもそもスプリントは短いので、途中でスプリントゴールをわざわざ変更する必要もない 17
18. スプリントプランニング DEEP DIVE 18 トピック2：このスプリントで何ができるのか？ 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログから アイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセス の中でプロダクトバックログアイテムのリファインメントをする場合がある。 そ れによって、チームの理解と自信が高まる。スプリント内でどれくらい完了でき るかを選択するのは難しいかもしれない。 しかしながら、開発者が過去の自分 たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めて いけば、スプリントの予測に自信が持てるようになる。 -- スクラムガイド2020
19. スプリントプランニング DEEP DIVE 19 大原則: 準備ができているプロダクトバックログアイテムだけを選択する ▸ 原則 「1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプラン ニングのときには選択の準備ができている」 （スクラムガイド） ▸ 「生煮えプロダクトバックログアイテムを食べると腹を壊す」 ▸ スプリント中に何度もプロダクトオーナーと仕様を確認することになる ▸ 着手したあとに、想像以上に規模が大きいことが分かる ▸ プロダクトオーナーに完成確認をしたときに、認識の相違が見つかる ▸ 結果的に、選択したプロダクトバックログアイテムが完成しない確率が高まる ▸ スプリントごとの成果の量が不安定になり、予測精度が下がる ▸ スクラムチームごとに、どこまで準備をすれば適切なのかは違う
20. スプリントプランニング DEEP DIVE 20 プロダクトバックログアイテムを必要に応じてさらにリファインメントする ▸ スプリントで着手するプロダクトバックログアイテムは準備ができていなければいけない ▸ つまり、このタイミングでも必要ならさらにリファインメントする ▸ 例えば、スプリントゴールを踏まえて、プロダクトバックログアイテムの中身をちょっと変える ▸ ただし「時すでに遅し」の場合もあるので、範囲は限定的になる ▸ 中身が全然詰まっていないようなものを扱っても、とても時間がかかる上に見落としが起きがち ▸ 選択しようとしているプロダクトバックログアイテムの見積りをスプリントプランニングで実施してい るようでは遅い
21. スプリントプランニング DEEP DIVE 21 PBI選択の大原則: スプリントゴールやスプリントレビューから逆算する ▸ スクラムの基本は「フィードバック」サイクルを回すこと ▸ プロダクトに対する定期的なフィードバックは成功の上でとても重要 ▸ 適切なスプリントゴールの設定、そのゴールを達成しているインクリメントをスプリントレビューで見せ ることを重視する必要がある ▸ インクリメントを見せられないのは論外 ▸ いま意味があるインクリメントを見せなければいけない ▸ スプリントプランニングの時点で、誰をスプリントレビューに呼ぶとよいかわからなければいけない ▸ これを踏まえてプロダクトバックログアイテムを選択する
22. スプリントプランニング DEEP DIVE 22 スプリントに投入するプロダクトバックログアイテムとスプリントゴールの関係 ▸ スプリントに投入するプロダクトバックログアイテムはスプリントゴールの達成に寄与するものが中心 になる ▸ ただし、現実的にはすべてのプロダクトバックログアイテムがそうなるとは限らない ▸ 将来の準備、バグの修正、セキュリティ対応、各種調査、リファクタリングなどの対応が必要 ▸ スプリントゴール直結のプロダクトバックログアイテムとそれ以外（上述）のプロダクトバックログアイ テムの比率を7:3程度にすることも多い
23. スプリントプランニング DEEP DIVE スプリントで取り組むプロダクトバックログアイテムの量を決定するには？ ▸ できもしないものをたくさん積んでも仕方ない ▸ 過去のスプリントでどれくらいの量を完成できたかを参考にするのがよくある手 ▸ 完成したプロダクトバックログアイテムの数 ▸ 完成したプロダクトバックログアイテムの見積りの合計 ▸ おおよその感覚値でも使える ▸ 経験を積むごとに、どれくらいの量をこなせるかの予測の精度は上がっていく ▸ スプリントで使える時間にばらつきがある場合は、それを明らかにするのも役に立つことが多い 23
24. スプリントプランニング DEEP DIVE ベロシティ ▸ スクラム用語ではない（ユーザーストーリーもストーリーポイントも同様） ▸ ……が一般的によく使われるプラクティス ▸ 1つのスプリントのなかで完成したプロダクトバックログアイテムの見積りを合計したもの ▸ たとえば、5ポイント、3ポイント、2ポイントのアイテムが完成した場合は、ベロシティは10ポイント ▸ 直近数スプリントの数値を参考にするとよい（昨日の天気） ▸ 乱高下しているようだと、計画づくりにも使いにくい ▸ 予測を始めとして、スクラムチーム自身のために使う ▸ スクラムチーム外に、管理用に利用するものではない（やめろ） 24
25. スプリントプランニング DEEP DIVE 25 キャパシティ ▸ 計画のとき多くの組織は1日を8時間として計算 している ▸ つまり1週間40時間を開発に使えると考えがち ▸ 実際はまったくそんなことはない ▸ 右の例だと実際に開発に使えるのは60% (平均で50〜70%) ▸ あらかじめバッファーを確保する ▸ これらを踏まえて残った時間がキャパシティ 項目 時間 社内全体会議 1 事務手続き・報告・メール 2 研修 2 休暇 4 スクラムイベント 5 プロダクトバックログリファインメント 2 開発作業 24
26. スプリントプランニング DEEP DIVE 26 トピック3：選択した作業をどのように成し遂げるのか？ 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たす インクリメントを作成するために必要な作業を計画する。 これは多くの場合、プ ロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することに よって行われる。 これをどのように行うかは、開発者だけの裁量とする。 プロダ クトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてく れない。 -- スクラムガイド2020
27. スプリントプランニング DEEP DIVE 作業を計画する ▸ スクラムガイドを踏まえると ▸ タスクに分解しなければいけないわけではない ▸ タスクを見積もらなければいけないわけでもない ▸ 開発者による開発者のための計画 ▸ 自分たちがデイリースクラムで日々検査して、適応できるような作業計画であればよい ▸ 日々状況に応じて更新する ▸ 目指すべきはすべての作業を行うことではなく、スプリントゴールを達成すること 27
28. スプリントプランニング DEEP DIVE 28 タスク分割以外の実行計画の例 グ バ プ タルツールは有害 : ス リント ックロ 」、オライリー・ジャパン、2021年） だ ジ デ 出典 『スクラム実践者が知るべき97のこと』（p.63 「
29. スプリントプランニング DEEP DIVE タスク分割による実行計画のたて方のよくある例 ▸ スプリントで実施するプロダクトバックログアイテムをタスクに細分化する ▸ よくあるやり方 ▸ タスクを理想時間(邪魔がない場合の所要時間)単位で開発者みんなで見積もる ▸ 平均的なスキルの開発者を基準にする ▸ 1タスクの最大時間は1日くらいまでにする (慣れないうちは2-3時間にすることも多い) 29
30. スプリントプランニング DEEP DIVE タスクの見積りにバッファを持たせない 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する -- パーキンソンの法則（第1法則） 30
31. fi スプリントプランニング DEEP DIVE 31 スプリントバックログのタスクの例（チーム内で引き継ぎが頻発しやすい例） # タスク 1 htmlテンプレートの作成 8 2 受け入れテストの作成 5 3 xtureの準備 見積り(h) 2 4 テーブルスキーマの作成（マイグレーション） 2 5 モデルの作成（ユニットテスト含む） 8 6 コントローラーの作成 4 7 仕様書のWikiを更新する 2 8 ヘルプファイルの更新 2 9 Jenkinsにプラグインを導入する 5 性能測定をおこなう 3 10
32. スプリントプランニング DEEP DIVE 32 スプリントバックログのタスクの例（完成へのリスクが徐々に減っていく例） # タスク 1 RDBに注文情報を登録できるようにする（SQLで） 8 2 画面から注文情報を登録できるようにする（注文内容は固定値） 5 3 最小限の受入テストを書く（これ以降は実装ごとに更新） 2 4 品目を選べるようにする（品目マスターを参照する） 2 5 数量を選べるようにする 8 6 色を選べるようにする 4 7 合計金額を計算できるようにする 2 8 注文者リクエストを入力できるようにする 2 9 入力画面のデザインを更新する 5 ・・・・・・ 3 10 見積り(h)
33. スプリントプランニング DEEP DIVE 33 SMARTなタスク ▸ Speci c：関係者全員が理解できるくらい具体的であること。それによって他のタスクとの重複を防ぐ ▸ Measurable：測定可能。そのタスクの終了条件について全員が同じ理解を持っていること ▸ Achievable：達成可能。誰もがタスクを達成するのに必要な助けを他の開発者に求めることが出来る ▸ Relevant：全てのタスクはプロダクトバックログアイテムの達成と関係があること fi ▸ Time-boxed：時間で見積もりが行われていること。もしタスクが見積もりより時間がかかりそうだった り難しそうだったら複数のタスクに分割されること
34. スプリントプランニング DEEP DIVE タスクの扱い方のヒント ▸ 開発者自身がタスクを選択し、指示による割り当てを避ける（指示する人はスクラムにはいない） ▸ 事前にすべての担当を決めない（ゴール達成を阻害する） ▸ 開発者はスプリントバックログを継続的に更新する ▸ 作業が不明確な場合は大きな時間を割り当てたタスクを定義し、後で細分化する 34
35. スプリントプランニング DEEP DIVE 35 スプリントバックログ スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、お よびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。 -- スクラムガイド2020
36. スプリントプランニング DEEP DIVE スプリントバックログとは ▸ スプリントゴール + 選択したプロダクトバックログアイテム＋実行計画をあわせたもの ▸ スクラムガイド2010では、分解したタスクのことをスプリントバックログと呼んでいたが今は違う ▸ 「スプリントバックログアイテム」という単語は存在しない 36
37. スプリントプランニング DEEP DIVE 37 スプリントプランニングにおけるコミットメント（確約） ▸ スプリントプランニングが終了した時点で、スクラムチームはスプリントゴールの達成に自信が持てる 状態になっていなければいけない ▸ もちろん自信を持って開始してもそのとおりにならないことはある ▸ だが、自信が持てない状態で見切り発車するのは疑問 ▸ できもしない約束をするのも無意味
38. スプリントプランニング DEEP DIVE まとめ：スプリントプランニング開始に向けた準備 ▸ 準備完了(Ready)したプロダクトバックログがあること ▸ スプリントゴールの元となるテーマが検討してあること ▸ プロダクトバックログの並び順が最新になっていること ▸ 上位は具体的で開発者が何を達成すればよいか明らかなこと ▸ 上位は見積り済みで、スプリントに十分収まるサイズであること ▸ 過去のスプリントでの成果の量(ベロシティなど)が分かっていること ▸ 開発に使えるキャパシティが明らかになっていること ▸ 完成の定義を十分に理解していること 38
39. スプリントプランニング DEEP DIVE まとめ：スプリントプランニングの進め方の例 ▸ チェックイン、タイムボックスやアジェンダの確認 ▸ プロダクトの全体像を確認する ▸ マーケットやビジネス状況の変化など影響のある情報を共有する ▸ 既知の問題や懸念を共有する ▸ 直近数スプリントの成果の量(ベロシティなど)を確認する ▸ 開発者がスプリントで使えるキャパシティ(作業可能な時間の合計など)を確認する ▸ プロダクトオーナーはどう価値を高めたいか説明し、スクラムチームでスプリントゴールを検討する 39
40. スプリントプランニング DEEP DIVE 40 まとめ：スプリントプランニングの進め方の例 (つづき) ▸ 対象としたいプロダクトバックログアイテムをプロダクトオーナーが説明する ▸ 開発者が内容に不明点がある場合はリファインメントを行う ▸ 開発者はプロダクトバックログアイテムがスプリントで入りそうか確認する ▸ 開発者は作業計画をたてる（タスクに分解して時間で見積もることもある） ▸ 作業計画と開発者のキャパシティを比較し問題ないか確認する ▸ スプリントゴール、選択したプロダクトバックログアイテム、作業計画を確認して、問題なければスプリ ントプランニングを終了する ▸ これらの活動をスクラムマスターは支援する
41. スプリントプランニング DEEP DIVE 41 こんなときどうする？ (1) スプリントプランニングが時間内に終わらない ▸ スプリントプランニングは1か月スプリントで8時間。期間が短ければその分短縮することが多い ▸ 1週間スプリントなら2時間、2週間スプリントなら4時間 ▸ スクラムのイベントはタイムボックス（スプリントを除く） ▸ 早く終る分には構わないが延長はしない ▸ 時間内に終わらない理由を見つけて直す ▸ タイムボックスを守れない状況が頻発するのは、スクラムチームの重大な問題 ▸ レトロスペクティブで取り上げる ▸ 時間で強制的に切るようにして延長グセを直す（スプリントの時間が余ったらもう一度やればいい）
42. スプリントプランニング DEEP DIVE こんなときどうする？ (2) スクラムチームのスキルにバラツキがある ▸ バラツキのサイン ▸ スプリントプランニングの長時間化 ▸ 一部の人だけによるスプリントプランニングや、各自個別での作業計画の作成 ▸ 特定の人への依存、特定の種類の作業の遅延 ▸ バラツキを制約とみなして、そのままなんとかしようとするのは悪手 ▸ クロスファンクショナルの度合いを上げることに時間を使ったほうがよいことが多い ▸ ペアプロ、モブプロ、勉強会などをスプリントプランニングで計画する 42
43. スプリントプランニング DEEP DIVE こんなときどうする？ (3) 障害や問い合わせなど割り込みが多い ▸ 割り込みの発生を前提として計画を立てる ▸ つまり、一定のキャパシティ（例えば20%）を空けておく ▸ スプリントレトロスペクティブなどで割り込みを分析する ▸ 定常作業として、プロダクトバックログアイテム化できるものはないか ▸ 同じことをしなくて済むように対処する方法はないか ▸ 実際にどの程度の割り込みがあったのか ▸ そもそもスプリント中に急いで対処すべきものだったのか ▸ これらを踏まえて、その後のスプリントの割り込み用キャパシティを検討する 43
44. スプリントプランニング DEEP DIVE こんなときどうする？ (4) プロダクトオーナーが十分参加できない ▸ スプリントプランニングでは、プロダクトオーナーと開発者の会話がたくさん必要 ▸ もちろんそれ以外のイベントでも ▸ プロダクトオーナーは単一障害点になりやすく、プロダクトオーナーが機能しないと迷走しやすい ▸ プロダクトオーナー不在でもなんとかする方法を見つけようとするのはムダ ▸ 「プロダクトオーナー不在という問題」そのものを解決しろ ▸ プロダクトオーナー交代 ▸ プロダクトオーナーが抱えている仕事を引き取る ▸ その他あの手この手で 44
45. スプリントプランニング DEEP DIVE こんなときどうする？ (5) 納期やマイルストーンがある ▸ 見積りは見積りに過ぎない ▸ できもしない計画を立てても無意味 ▸ チームの能力を超えた量のプロダクトバックログアイテムを選んでも仕方ない ▸ スクラムチームの能力はゆるやかにしか向上しない ▸ ベロシティを倍にする、みたいなのは無意味 ▸ できるのは、見通しを更新し続けること、スコープを調整し続けること 45
