スプリントプランニング Deep Dive 2026 改定版

2022年に公開したスプリントプランニング Deep Diveを2026年3月現在の状況にあわせて改定した資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. ２０２６年改訂版 スプリントプランニング Deep Dive 2026/3/19 fi 株式会社アトラクタ / Certi ed Scrum Trainer (CST) 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. 自己紹介 過去のDeep Diveシリーズ ▸ スプリントレトロスペクティブ Deep Dive ▸ ベロシティ Deep Dive ▸ スプリントレビュー Deep Dive ▸ スプリントプランニング Deep Dive ▸ プロダクトバックログ Deep Dive ▸ 資料は https://www.ryuzee.com/scrum-deep-dive/ を参照してください Deep Diveシリーズをプライベート研修にしました（3〜4時間）。お気軽にお問い合わせください。 4
6. スプリントプランニング DEEP DIVE 2026 6 “ 計画それ自体に価値はないが、 立案はすべてに勝る ” ドワイト・D・アイゼンハワー 第34代アメリカ大統領 Source:https://en.wikipedia.org/wiki/Dwight_D._Eisenhower
7. スプリントプランニング DEEP DIVE 2026 7 スプリントプランニングとは？ スプリントプランニングはスプリントの起点であり、ここではスプリントで実行す る作業の計画を立てる。 結果としてできる計画は、スクラムチーム全体の共同 作業によって作成される。 (中略) スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプラ ンニングに招待してもよい。 -- スクラムガイド2020
8. スプリントプランニング DEEP DIVE 2026 スプリントプランニングとは？ ▸ スプリントの冒頭で行う計画づくり ▸ スプリントの起点になる ▸ 生成AIをばんばん使うようになってスプリント期間は短縮傾向にあるが、依然として計画づくりは重要 ▸ 計画を立てずに仕事をする人はいない ▸ ただし仕事のやり方が変われば、計画の立て方も変わる 8
9. スプリントプランニング DEEP DIVE 2026 スプリントプランニングの参加者 ▸ スプリントプランニングは、スクラムチームの共同作業 ▸ [必須] プロダクトオーナー ▸ [必須] 開発者全員 ▸ [必須] スクラムマスター ▸ 必要な場合は外部の関係者を呼んでもよい 9
10. スプリントプランニング DEEP DIVE 2026 10 スプリントプランニング プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテ ムと、それらとプロダクトゴールとの関連性について話し合う準備ができている かを確認する。 -- スクラムガイド2020 「確認する」って どういうことだろう？
11. スプリントプランニング DEEP DIVE 2026 11 スプリントプランニング 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（英語版） 〔～を〕確かにする、保証す る、請け合う、確保する
12. スプリントプランニング DEEP DIVE 2026 12 つまり？ ▸ = 「プロダクトオーナーは、参加者が最も重要なプロダクトバックログアイテムと、それらとプロダクト ゴールとの関連性について話し合う準備が、確実にできているようにする」 ▸ 以下のような準備が必要になる ▸ プロダクトバックログが最新になっている ▸ 参加者が内容をある程度理解している （だいたい作れそうという感覚を持てている） ▸ すなわち十分リファインメントできている ▸ 「十分リファインメントできている」がどんな状態なのかは生成AIによって大きく変化した
13. スプリントプランニング DEEP DIVE 2026 13 トピック1：このスプリントはなぜ価値があるのか？ プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのよ うに高めることができるかを提案する。 次に、スクラムチーム全体が協力して、 そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴ ールを定義する。 スプリントゴールは、スプリントプランニングの終了までに確 定する必要がある。 -- スクラムガイド2020
14. スプリントプランニング DEEP DIVE 2026 プロダクトオーナーの提案から始まる ▸ プロダクトオーナーは、プロダクトの価値を最大化することについて説明責任を持つ ▸ そこで、今回のスプリントでプロダクトの価値や有用性をどう高めたいかを提案する ▸ つまりスプリントゴールの元ネタ ▸ 決定事項ではなく、命令でもない ▸ 議論の始まり ▸ スクラムチームの会話をもとに、スプリントプランニング終了までにスプリントゴールに落とし込む 14
15. スプリントプランニング DEEP DIVE 2026 スプリントゴールとは ▸ スプリントの目的や達成したいことを簡単にまとめたもの ▸ スプリントゴールはスプリントの唯一の目的 ▸ つまり選択したプロダクトバックログアイテムをすべて完成させることは目的ではない ▸ ステークホルダーに伝える。つまりステークホルダーが理解できるものでなければいけない ▸ 説明責任を果たす ▸ スプリントプランニングの終了までに確定する ▸ スプリントゴールはスクラムチームが協力して作る ▸ プロダクトオーナーが提示してそれでおしまいというわけではない 15
16. スプリントプランニング DEEP DIVE 2026 16 なぜスプリントゴールが必要か ▸ スプリント中に集中すべきことが明確になり、スクラムチーム内外の協力が得やすくなる ▸ ゴールの達成に向けて柔軟性が生まれる（アウトカム＞アウトプット） ▸ ゴールを踏まえてプロダクトバックログアイテムを明確に並べられるようになる ▸ スプリントレビューに誰を呼べばよいかわかりやすくなり、適切なフィードバックが得られるようになる ▸ スプリントの意味がわかりやすくなり、今何をやっているかステークホルダーに伝えやすくなる ▸ 前スプリントとの差分が、明確に意味を持つ状態になり、リリースするかどうかの判断がしやすくなる
17. スプリントプランニング DEEP DIVE 2026 生成AI時代はスプリントゴールの重要性がさらに向上 ▸ 生成AIによって実装や調査にかかる時間が大幅に短縮された ▸ 方向性が曖昧だと、価値の低いものや間違ったもの高速かつ大量に作れてしまう ▸ しかし、それはプロダクトにダメージを及ぼす ▸ これを避けるために、「どんな課題を解決するか」という意思決定の重要性がさらに高まった ▸ スプリントゴールがあることでチームが目指す価値と成果の方向性を明確にできる ▸ スプリントゴールが明確であればAIの活用方法や実装のアプローチを柔軟に変えることができる 17
18. スプリントプランニング DEEP DIVE 2026 スプリントゴールの例（機能ではなく課題にアプローチする） 達成できたかを評価しやすい例 コンバージョンレートを増加するために、購入に必要なステップ数を減らす ページの読み込み時間を2秒以内にする サポート問い合わせのうち「使い方がわからない」系を30%減らす 古いログイン画面のデザインを見直し、ログイン操作の誤操作回数を30%削減 既存の重大バグによるユーザーの離脱を止める 登録機能のUXをユーザーテストで確認できるようにする デザイン変更 (1) 主要導線部分を新デザインに変更し評価可能にする プロダクトバックログアイテムごとの価値を計測できるようにする 18
19. スプリントプランニング DEEP DIVE 2026 スプリントゴールはスプリント中は不変 ▸ スプリントゴールはスプリント中は不変 ▸ スプリントゴールを犠牲にしても優先しなければいけないゴールが登場した場合は、スプリントを キャンセルする ▸ スプリントゴールをスプリント中に変えると？ ▸ 多くのムダを生み出す（仕掛り中を途中で放置するなど） ▸ 作業内容が増え、チームが危険にさらされる ▸ そもそもスプリントは短いので、途中でスプリントゴールをわざわざ変更する必要もない 19
20. スプリントプランニング DEEP DIVE 2026 20 トピック2：このスプリントで何ができるのか？ 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログから アイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセス の中でプロダクトバックログアイテムのリファインメントをする場合がある。 そ れによって、チームの理解と自信が高まる。スプリント内でどれくらい完了でき るかを選択するのは難しいかもしれない。 しかしながら、開発者が過去の自分 たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めて いけば、スプリントの予測に自信が持てるようになる。 -- スクラムガイド2020
21. スプリントプランニング DEEP DIVE 2026 21 大原則: 準備ができているプロダクトバックログアイテムだけを選択する ▸ プロダクトバックログアイテムの選択は会話を通じて開発者が最終判断（説明責任と確約） ▸ 原則 「1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプラ ンニングのときには選択の準備ができている」 （スクラムガイド） ▸ 「生煮えプロダクトバックログアイテムを食べると腹を壊す」 ▸ スプリント中に何度もプロダクトオーナーと仕様を確認することになる ▸ 着手したあとに、想像以上に規模が大きいことが分かる ▸ プロダクトオーナーに完成確認をしたときに、認識の相違が見つかる ▸ 結果的に、スプリントゴールを達成できない可能性が高まる ▸ スクラムチームごとに、どこまで準備をすれば適切なのかは違う
22. スプリントプランニング DEEP DIVE 2026 生成AIを使った開発におけるスプリントの準備 ▸ 生成AIは曖昧な指示や不足した情報を誤った形で補完してしまう（想像してしまう） ▸ プロダクトバックログアイテムで、解決したい課題や目的が明確になっている必要がある ▸ 次のような情報が整理されているとよい（これも検査と適応の対象） ▸ ユーザーや利用シナリオ、ドメインルールや業務制約、データ構造や既存システムとの関係 ▸ 期待されるふるまいや受け入れ条件 ▸ これらが整理されているほどAIによる実装や検証を効果的に進められる ▸ つまり、生成AI時代では、コンテキストの準備がより重要になる（本来からこうあるべきだが） ▸ ただし、スプリント中でも間に合うことをすべて事前にやる必要はない 22
23. スプリントプランニング DEEP DIVE 2026 スプリントプランニングでPBIを必要に応じてさらにリファインメントする ▸ スプリントで着手するプロダクトバックログアイテムは準備ができていなければいけない ▸ つまり、このタイミングでも必要ならさらにリファインメントする ▸ 例えば、スプリントゴールを踏まえて、プロダクトバックログアイテムの中身をちょっと変える ▸ ただし「時すでに遅し」の場合もあるので、なんでも対象にしない ▸ いくら生成AIを使うとはいえ、中身が全然詰まっていないPBIで期待通りのものを作るのは大変 ▸ スプリントプランニングのタイムボックスを守れないような状況はこれが原因のことが多い 23
24. スプリントプランニング DEEP DIVE 2026 24 PBI選択の大原則: スプリントゴールやスプリントレビューから逆算する ▸ スクラムの基本は「フィードバック」サイクルを回すこと ▸ プロダクトに対する定期的なフィードバックは成功の上でとても重要 ▸ 適切なスプリントゴールの設定、そのゴールを達成しているインクリメントをスプリントレビューで見せ ることを重視する必要がある ▸ インクリメントを見せられないのは論外 ▸ いま意味があるインクリメントを見せなければいけない ▸ スプリントプランニングの時点で、誰をスプリントレビューに呼ぶとよいかわからなければいけない ▸ これを踏まえてプロダクトバックログアイテムを選択する
25. スプリントプランニング DEEP DIVE 2026 25 スプリント内で完成するサイズのプロダクトバックログアイテムを選択する ▸ ゴールを短い周期で検査するために、スプリントで完成させるという原則は生成AI時代も変わらない XL (途中まで作り、残ったものは次のスプリント) ✕ L ※1 △ M ◯ M M L ◯ ※2 ✕ L S S S M S S S S S S S S S S S ※1 最初のLに手間取ると2個目着手時点で完成しないことが目に見えている。 ※2 スプリントゴールが不明瞭な可能性
26. スプリントプランニング DEEP DIVE 2026 26 スプリントに投入するプロダクトバックログアイテムとスプリントゴールの関係 ▸ スプリントに投入するプロダクトバックログアイテムはスプリントゴールの達成に寄与するものが中心 になる ▸ ただし、現実的にはすべてのプロダクトバックログアイテムがそうなるとは限らない ▸ 将来の準備、バグの修正、セキュリティ対応、各種調査、リファクタリングなどの対応が必要 ▸ スプリントゴール直結のプロダクトバックログアイテムとそれ以外（上述）のプロダクトバックログアイ テムの比率を7:3程度にすることも多い
27. スプリントプランニング DEEP DIVE 2026 スプリントで取り組むプロダクトバックログアイテムの量を決定するには？ ▸ できもしないものをたくさん積んでも仕方ない ▸ 過去のスプリントでどれくらいの量を完成できたかを参考にするのがよくある手 ▸ 完成したプロダクトバックログアイテムの数 ▸ 完成したプロダクトバックログアイテムの見積りの合計（ベロシティ） ▸ ただし最近は細かい「ベロシティ」に意味がなくなりつつある ▸ おおよその感覚値でも使える。だんだん予測の精度は上がっていく ▸ スプリントで使える時間（キャパシティ）にばらつきがある場合は、それを明らかにするのも役に立つ 27
28. スプリントプランニング DEEP DIVE 2026 ベロシティの意味は変化しつつある ▸ いままでは開発作業にいちばん時間がかかっていてリスクが大きかった ▸ そのため詳細に見積もり、事前にしっかり確認することに意味があった ▸ 生成AIの登場によって開発作業自体がリスクではなくなりつつある ▸ それなりに大きい規模でも、PBIの具体性が高ければ1スプリントで完成できる ▸ つまり、関心事は「1スプリントに収まりそうか」、「何個くらいできそうか」くらい ▸ 見積りはストーリーポイントで1,2,3,5,8,13……まで見るのではなく、小中大（特大）くらいで十分 ▸ スプリントに収まるか、スプリントで完成できるかのほうが重要 ▸ 「この3つならスプリントに入る」くらいの精度でも十分なこともある 28
29. スプリントプランニング DEEP DIVE 2026 29 キャパシティ（割り込みが多いチームなら役に立つことも） ▸ 計画のとき多くの組織は1日を8時間として計算 している 項目 時間(1週あたり) 社内全体会議 1 ▸ つまり1週間40時間を開発に使えると考えがち 事務手続き・報告・メール 2 ▸ 実際はまったくそんなことはない 研修 2 ▸ 右の例だと実際に開発に使えるのは60% (平均で50〜70%) 休暇 4 スクラムイベント 5 プロダクトバックログリファインメント 2 開発作業 24 ▸ あらかじめバッファーを確保する ▸ これらを踏まえて残った時間がキャパシティ
30. スプリントプランニング DEEP DIVE 2026 30 トピック3：選択した作業をどのように成し遂げるのか？ 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たす インクリメントを作成するために必要な作業を計画する。 これは多くの場合、プ ロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することに よって行われる。 これをどのように行うかは、開発者だけの裁量とする。 プロダ クトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてく れない。 -- スクラムガイド2020
31. スプリントプランニング DEEP DIVE 2026 作業を計画する ▸ スクラムガイドを踏まえると ▸ タスクに分解しなければいけないわけではない ▸ タスクを見積もらなければいけないわけでもない ▸ 生成AIに作業させるならなおさら ▸ 開発者による開発者のための計画 ▸ 自分たちがデイリースクラムで日々検査して、適応できるような作業計画であればよい ▸ 日々状況に応じて更新する ▸ 目指すべきはすべての作業を完成させることではなく、スプリントゴールを達成すること 31
32. スプリントプランニング DEEP DIVE 2026 32 タスク分割以外の実行計画の例 グ バ プ タルツールは有害 : ス リント ックロ 」、オライリー・ジャパン、2021年） だ ジ デ 出典 『スクラム実践者が知るべき97のこと』（p.63 「
33. スプリントプランニング DEEP DIVE 2026 生成AI登場前のスプリントバックログの実行計画の例 # 実行計画 1 RDBに注文情報を登録できるようにする（SQLで） 2 画面から注文情報を登録できるようにする（注文内容は固定値） 3 最小限の受入テストを書く（これ以降は実装ごとに更新） 4 品目を選べるようにする（品目マスターを参照する） 5 数量を選べるようにする 6 色を選べるようにする 7 合計金額を計算できるようにする 8 注文者リクエストを入力できるようにする 9 入力画面のデザインを更新する 10 ・・・・・・ 生成AI登場前によくやってた方法。今は、生成AIで一気にできる可能性もある。 一方で妥当性を1スプリントの中で確認しきれなければ未完成になるので、バランスを取る必要がある 33
34. スプリントプランニング DEEP DIVE 2026 生成AI時代の実行計画とプロダクトバックログアイテムの関係 ▸ 生成AIで実装が速くなると、実行計画で考えることが減る（前ページのようにやる必要がない） ▸ 一方で「意味のある動く単位に分割してから渡す」必要があるため、分割の判断が重要になる ▸ その分割はスプリントプランニングで考えるより、リファインメントで済ませておくべきこと ▸ つまり、実行計画で悩む時間が減った分、リファインメントの質がより問われるようになった ▸ 「実行計画が薄い＝準備不足」ではなく、「準備が十分できていれば実行計画は薄くなる」 34
35. スプリントプランニング DEEP DIVE 2026 35 実行計画の扱い方のヒント ▸ 開発者自身が作業を選択し、指示による作業割り当てを避ける（指示する人はスクラムにはいない） ▸ 事前にすべての作業の担当を決めない（ゴール達成を阻害する） ▸ 開発者はスプリントバックログを継続的に更新する ▸ 作業が不明確な場合は大きな時間を割り当てたタスクを定義し、後で細分化する ▸ 生成AIの活用度合い、アーキテクチャー、コーディング以外の作業量によって、実行計画は大きく変わる ▸ つまり実行計画をどう立てるかは検査と適応の対象
36. スプリントプランニング DEEP DIVE 2026 36 スプリントバックログ スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、お よびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。 -- スクラムガイド2020
37. スプリントプランニング DEEP DIVE 2026 スプリントバックログとは ▸ スプリントゴール + 選択したプロダクトバックログアイテム＋実行計画をあわせたもの ▸ スクラムガイド2010-2011では、分解したタスクのことをスプリントバックログと呼んでいた ▸ 「スプリントバックログアイテム」という単語は現在のスクラムガイドには存在しない 37
38. スプリントプランニング DEEP DIVE 2026 38 スプリントプランニングにおけるコミットメント（確約） ▸ スプリントプランニングが終了した時点で、スクラムチームはスプリントゴールの達成に自信が持てる 状態になっていなければいけない ▸ もちろん自信を持って開始してもそのとおりにならないことはある ▸ だが、自信が持てない状態で見切り発車するのは疑問 ▸ できもしない約束をするのも無意味 ▸ だからこそ、スプリントプランニングで、どのプロダクトバックログアイテムを選択するかを最終的に判 断するのが開発者になる
39. スプリントプランニング DEEP DIVE 2026 まとめ：スプリントプランニング開始に向けた準備 ▸ 準備完了した(Readyな)プロダクトバックログがあること ▸ スプリントゴールの元となるテーマが検討してあること ▸ プロダクトバックログアイテムの並び順が最新になっていること ▸ 上位は具体的で開発者が何を達成すればよいか明らかなこと ▸ 上位はサイズがおおよそ明らかで、スプリントに十分収まるサイズであること ▸ 過去のスプリントでの成果の量が分かっていること ▸ 開発に使えるキャパシティが明らかになっていること ▸ 完成の定義を十分に理解していること 39
40. スプリントプランニング DEEP DIVE 2026 まとめ：スプリントプランニングの進め方の例 ▸ チェックイン、タイムボックスやアジェンダの確認 ▸ プロダクトの全体像を確認する ▸ マーケットやビジネス状況の変化など影響のある情報を共有する ▸ 既知の問題や懸念を共有する ▸ 直近数スプリントの成果の量を確認する ▸ 開発者がスプリントで使えるキャパシティを確認する ▸ プロダクトオーナーはどう価値を高めたいか説明し、スクラムチームでスプリントゴールを検討する 40
41. スプリントプランニング DEEP DIVE 2026 41 まとめ：スプリントプランニングの進め方の例 (つづき) ▸ 対象としたいプロダクトバックログアイテムをプロダクトオーナーが説明する ▸ 開発者が内容に不明点がある場合はリファインメントを行う（ただし全部だとしたら準備不足） ▸ これらを踏まえて、開発者がプロダクトバックログアイテムを選択する ▸ 開発者はプロダクトバックログアイテムがスプリントで入りそうか確認する ▸ 開発者は作業計画をたてる ▸ 作業計画がキャパシティに収まりそうかを確認する ▸ スプリントゴール、選択したPBI、作業計画を確認して、問題なければスプリントプランニングを終了する ▸ これらの活動をスクラムマスターは支援する
42. スプリントプランニング DEEP DIVE 2026 生成AI時代のスプリントプランニング ── 変わること・変わらないこと ▸ 変わらないこと ▸ スプリントゴールを定めて、短い周期でフィードバックを得るという原則 ▸ スプリント内で完成させるという原則 ▸ 準備できていないプロダクトバックログアイテムを選択しないという原則 ▸ 開発者が自分たちで判断し、確約するという原則 ▸ 変わること ▸ 「十分リファインメントできている」の基準 ── コンテキストの準備がより重要になる ▸ ベロシティの意味 ── 細かい見積りより「スプリントに収まるか」が関心事 ▸ 実行計画の粒度 ── 手順の列挙より、動く単位への分割がリファインメントで前倒しになる ▸ スプリントゴールの重要性 ── 方向性が曖昧なまま高速に作れてしまうため、むしろ高まる 42
43. Q&A
44. APPENDIX
45. スプリントプランニング DEEP DIVE 2026 45 こんなときどうする？ (1) スプリントプランニングが時間内に終わらない ▸ スプリントプランニングは1か月スプリントで8時間。期間が短ければその分短縮することが多い ▸ 1週間スプリントなら2時間、2週間スプリントなら4時間 ▸ スクラムのイベントはタイムボックス（スプリントを除く） ▸ 早く終る分には構わないが延長はしない ▸ 時間内に終わらない理由を見つけて直す ▸ タイムボックスを守れない状況が頻発するのは、スクラムチームの重大な問題 ▸ レトロスペクティブで取り上げる ▸ 時間で強制的に切るようにして延長グセを直す（スプリントの時間が余ったらもう一度やればいい）
46. スプリントプランニング DEEP DIVE 2026 こんなときどうする？ (2) スクラムチームのスキルにバラツキがある ▸ バラツキのサイン ▸ スプリントプランニングの長時間化 ▸ 一部の人だけによるスプリントプランニングや、各自個別での作業計画の作成 ▸ 特定の人への依存、特定の種類の作業の遅延 ▸ バラツキを制約とみなして、そのままなんとかしようとするのは悪手 ▸ クロスファンクショナルの度合いを上げることに時間を使ったほうがよいことが多い ▸ ペアプロ、モブプロ、勉強会などをスプリントプランニングで計画する 46
47. スプリントプランニング DEEP DIVE 2026 こんなときどうする？ (3) 障害や問い合わせなど割り込みが多い ▸ 割り込みの発生を前提として計画を立てる ▸ つまり、一定のキャパシティ（例えば20%）を空けておく ▸ スプリントレトロスペクティブなどで割り込みを分析する ▸ 定常作業として、プロダクトバックログアイテム化できるものはないか ▸ 同じことをしなくて済むように対処する方法はないか ▸ 実際にどの程度の割り込みがあったのか ▸ そもそもスプリント中に急いで対処すべきものだったのか ▸ これらを踏まえて、その後のスプリントの割り込み用キャパシティを検討する 47
48. スプリントプランニング DEEP DIVE 2026 こんなときどうする？ (4) プロダクトオーナーが十分参加できない ▸ スプリントプランニングでは、プロダクトオーナーと開発者の会話がたくさん必要 ▸ もちろんそれ以外のイベントでも ▸ プロダクトオーナーは単一障害点になりやすく、プロダクトオーナーが機能しないと迷走しやすい ▸ プロダクトオーナー不在でもなんとかする方法を見つけようとするのはムダ ▸ 「プロダクトオーナー不在という問題」そのものを解決しろ ▸ プロダクトオーナー交代 ▸ プロダクトオーナーが抱えている仕事を引き取る ▸ その他あの手この手で 48
49. スプリントプランニング DEEP DIVE 2026 こんなときどうする？ (5) 納期やマイルストーンがある ▸ 見積りは見積りに過ぎない ▸ できもしない計画を立てても無意味 ▸ チームの能力を超えた量のプロダクトバックログアイテムを選んでも仕方ない ▸ スクラムチームの能力はゆるやかにしか向上しない ▸ ベロシティを倍にする、みたいなのは無意味 ▸ できるのは、見通しを更新し続けること、スコープを調整し続けること 49

Comment

No comments...