エッセンシャル スクラム
翔泳社
著者：Kenneth S. Rubin
訳者：和智右桂、髙木正弘、岡澤裕二、角征典
「エッセンシャル スクラム」への賛辞
Mike Cohnによる序文
Ron Jeffriesによる序文
まえがき
謝辞
著者について
第1章 イントロダクション
1.1 スクラムとは何か？
1.2 スクラムの起源
1.3 なぜスクラムなのか？
1.4 ゲノミカ社の顛末
1.5 スクラムは役に立つか？
複雑な領域
込み入った領域
単純な領域
カオスな領域
無秩序
割り込み駆動の作業
1.6 終わりに. .
第I 部コアコンセプト
第2章 スクラムフレームワーク
2.1 概要
2.2 スクラムの役割
プロダクトオーナー
スクラムマスター
開発チーム
2.3 スクラムのアクティビティと作成物
プロダクトバックログ
スプリント
スプリントプランニング
スプリントの実施
デイリースクラム
完成
スプリントレビュー
スプリントレトロスペクティブ
2.4 終わりに
第3章 アジャイルの原則
3.1 概要
3.2 変動性と不確実性
役立つ変動性を受け入れよ
イテレーティブでインクリメンタルな開発を採用せよ
検査、適応、透明性を通じて変動性を活用せよ
あらゆる形の不確実性を同時に削減せよ
3.3 予見と適応
選択肢を広げておく
事前に正しく行うことは不可能だと認める
適応型で探索型のアプローチを好む
経済的に妥当なやり方で変化を受け入れる
予見的な事前の作業と適応型のジャストインタイムの作業とのバランスを取る
3.4 検証による学び
重要な想定をまず検証する
複数の学習ループを並行して活用する
すばやいフィードバックのためのワークフローをまとめる
3.5 仕掛中の作業（WIP）
作業は経済的に妥当なサイズにまとめよ
在庫を認識し、適切な流れで管理せよ
作業者の手待ちではなく、作業の手待ちに注目せよ
遅延コストを考慮せよ
3.6 進捗
リアルタイムの情報に適応して再計画せよ
動作する資産を検証することで進捗を測れ
価値に主眼を置いたデリバリーに集中せよ
3.7 作業効率
すばやく進め、しかし、あわてるな
品質を作り込め
必要最低限の儀式を行え
3.8 終わりに
第4章 スプリント
4.1 概要
4.2 タイムボックス化
WIPに上限を設ける
優先順位付けを強制する
進捗状況を可視化する
不必要な完璧主義を避ける
締めくくりの促進
予測可能性を改善する
4.3 短期間
計画の立てやすさ
すばやいフィードバック
投資収益率の改善
損失の限定化
熱狂を取り戻す
頻繁なチェックポイント
4.4 不変のスプリント期間
一定したリズムの利点
簡潔なプランニング
4.5 ゴールを変えない
スプリントゴールとは？
相互コミットメント
変更と明確化
変更の影響
実利的であるべし
スプリントの中止
4.6 完成の定義
「完成の定義」とは
「完成の定義」は時間と共に改善されていく
「完成の定義」と受け入れ条件
「完成」と「完全に完成」
4.7 終わりに
第5章 要件とユーザーストーリー
5.1 概要
5.2 対話する
5.3 改良し続ける
5.4 ユーザーストーリーとは何なのか
カード
対話
確認
5.5 詳細化のレベル
5.6 うまく書けたユーザーストーリーとINVEST
独立している
交渉できる
価値がある
見積もり可能
適切な大きさ（ほどほどに小さく）
テスト可能
5.7 非機能要件
5.8 学習のためのストーリー
5.9 ストーリーの収集
ユーザーストーリー記述ワークショップ
ストーリーマッピング
5.10 終わりに
第6章 プロダクトバックログ
6.1 概要
6.2 プロダクトバックログアイテム
6.3 よいプロダクトバックログの特徴
適切な詳細度
創発的
見積もり
優先順位付け
6.4 グルーミング
グルーミングとは
誰がグルーミングするのか
いつグルーミングするのか
6.5 準備完了の定義
6.6 フローの管理
リリースフローの管理
スプリントフローの管理
6.7 どんなプロダクトバックログをいくつ用意するか？
プロダクトとは何か
大規模なプロダクト―階層化バックログ
複数チーム―単一のプロダクトバックログ
単一のチーム―複数のプロダクト
6.8 終わりに
第7章 見積もりとベロシティ
7.1 概要
7.2 いつ何を見積もるのか
ポートフォリオバックログの見積もり
プロダクトバックログの見積もり
タスクの見積もり
7.3 PBIの見積もりの考え方
チームで見積もる
見積もりはコミットメントではない
正確性か精度か
相対サイズの見積もり
7.4 PBIの見積もりの単位
ストーリーポイント
理想日
7.5 プランニングポーカー
見積もりの尺度
やってみよう
メリット
7.6 ベロシティとは
7.7 ベロシティの幅の算出
7.8 ベロシティの予想
7.9 ベロシティへの影響
7.10 ベロシティの誤用
7.11 終わりに
第8章 技術的負債
8.1 概要
8.2 技術的負債の行く末
予測不可能な臨界
デリバリーに要する時間の長期化
不具合の多発
開発およびサポートのコストの増加
プロダクトの退化
予測可能性の減少
伸び悩み
募る不満
顧客満足度の減少
8.3 技術的負債を生む要因
納期を守るためのプレッシャー
ベロシティの偽装
テストを減らせばベロシティが向上するという神話
負債が生む新たな負債
8.4 技術的負債の管理
8.5 技術的負債の発生の管理
優れた技術的プラクティスの活用
厳しい完成の定義の使用
技術的負債の経済的意味についての適切な認識
8.6 技術的負債の可視化
ビジネスレベルでの技術的負債の可視化
技術者レベルでの技術的負債の可視化
8.7 技術的負債の返済
すべての技術的負債を返済すべきというわけではない
ボーイスカウトルールに従う（負債を見つけたらその場で返済する）
技術的負債の返済はインクリメンタルに
金利の高い技術的負債から返済する
技術的負債を返済しながら顧客に価値をもたらす作業も行う
8.8 終わりに
第II 部役割
第9章 プロダクトオーナー
9.1 概要
9.2 主な責任
経済性の管理
プランニングへの参加
プロダクトバックログのグルーミング
受け入れ条件の定義と検証
開発チームとの協力
ステークホルダーとの協力
9.3 特性とスキル
ドメインスキル
対人スキル
意思決定力
説明責任力
9.4 一日の様子
9.5 誰がプロダクトオーナーになるべきか？
社内開発
商用開発
外部委託開発
コンポーネント開発
9.6 その他の役割との組み合わせ
9.7 プロダクトオーナーチーム
プロダクトオーナープロキシ
チーフプロダクトオーナー
9.8 終わりに
第10章 スクラムマスター
10.1 概要
10.2 主な責任
コーチ
サーバントリーダー
プロセスの権威者
防御壁
インペディメントの除去
チェンジエージェント
10.3 特性とスキル
博識
質問力
辛抱強い
協力的
保護力
透明性
10.4 一日の様子
10.5 役割を果たす
誰がスクラムマスターになるべきか？
スクラムマスターはフルタイムジョブか？
スクラムマスターを他の役割と組み合わせる
10.6 終わりに
第11章 開発チーム
11.1 概要
11.2 役割別のチーム
11.3 主な責任
スプリントの実施
日々の検査と適応
プロダクトバックログのグルーミング
スプリントプランニング
プロダクトとプロセスの検査と適応
11.4 特性とスキル
自己組織化
機能横断的な多様性と十分な能力
T型スキル
銃士の姿勢
広帯域のコミュニケーション
透明なコミュニケーション
適切な規模
集中とコミットメント
持続可能なペースで仕事する
長寿
11.5 終わりに
第12章 スクラムチームの構成
12.1 概要
12.2 フィーチャーチームかコンポーネントチームか
12.3 複数チーム間での調整
スクラムオブスクラム
リリーストレイン
12.4 終わりに
第13章 マネージャー
13.1 概要
13.2 チームを編成する
境界を定める
明確なゴールを定める
チームの体制を決める
チームの構成を変更する
チームに権限を持たせる
13.3 チームを育てる
チームを活気づける
能力を伸ばす
機能エリアのリーダーシップを発揮する
チームの安定を保つ
13.4 環境を合わせてなじませる
アジャイルの価値を広める
組織内のインペディメントを取り除く
社内調整
対外調整
13.5 価値創造の流れを作る
全体的な視点で考える
財政の管理
評価や報告の管理
13.6 プロジェクトマネージャー
スクラムチームにおけるプロジェクト管理の責務
プロジェクトマネージャーの役割を残す
13.7 終わりに
第III 部プランニング
第14章 スクラムのプランニングの原則
14.1 概要
14.2 事前にきちんと計画を作れると思うな
14.3 事前のプランニングのやりすぎに注意
14.4 プランニングの選択肢は、最終責任時点まで変更可能にする
14.5 計画を守ることよりも、計画の調整や再計画を重視する
14.6 計画の一覧をきちんと管理する
14.7 早めにリリース、頻繁にリリース
14.8 早めに学び、必要ならピボットする
14.9 終わりに
第15章 さまざまなレベルでのプランニング
15.1 概要
15.2 ポートフォリオプランニング
15.3 プロダクトプランニング（エンビジョニング）
ビジョン
概要レベルのプロダクトバックログ
プロダクトのロードマップ
15.4 リリースプランニング
15.5 スプリントプランニング
15.6 デイリープランニング
15.7 終わりに
第16章 ポートフォリオプランニング
16.1 概要
タイミング
参加者
プロセス
16.2 スケジューリングの戦略
ライフサイクル収益で最適化する
遅延コストを算出する
見積もるのは正確性であって、精度ではない
16.3 インフローの戦略
経済的フィルターの適用
追加と取り出しのバランスを取る
創発的なチャンスへのすばやい対応
小さめなリリースを頻繁に行うための計画
16.4 アウトフローの戦略
作業者の手待ちではなく、作業の手待ちに注目せよ
WIPを制限する
チーム全員の準備が整うのを待つ
16.5 仕掛品の戦略
限界費用を使う
16.6 終わりに
第17章 エンビジョニング（プロダクトプランニング）
17.1 概要
タイミング
参加者
プロセス
17.2 SR4Uの例
17.3 ビジョンづくり
17.4 概要レベルのプロダクトバックログの作成
17.5 プロダクトロードマップの定義
17.6 その他のアクティビティ
17.7 経済的に理にかなったエンビジョニング
現実的な信頼の閾値を目指す
注目するのは短期間だけ
すばやく動く
検証による学びに投資する
インクリメンタルに出資する
早めに学んでピボットする（フェイルファースト）
17.8 終わりに
第18章 リリースプランニング（長期計画）
18.1 概要
タイミング
参加者
プロセス
18.2 リリース制約
すべてを固定
スコープと期日を固定
スコープを固定
期日を固定
品質を可変に
制約の見直し
18.3 プロダクトバックログのグルーミング
18.4 リリース可能な最小限のフィーチャー（MRF）の見直し
18.5 スプリントマッピング（PBIの割り当て）
18.6 固定期日のリリースプランニング
18.7 固定スコープのリリースプランニング
18.8 コストの算出
18.9 コミュニケーション
固定スコープのリリースにおける進捗の把握
固定期日のリリースにおける進捗の把握
18.10 終わりに
第IV 部スプリント
第19章 スプリントプランニング
19.1 概要
タイミング
参加者
プロセス
19.2 スプリントプランニングの手法
二部構成のスプリントプランニング
一部構成のスプリントプランニング
19.3 キャパシティの決定
キャパシティとは？
ストーリーポイントを使ったキャパシティ
作業時間を使ったキャパシティ
19.4 プロダクトバックログアイテムの選択
19.5 自信の獲得
19.6 スプリントゴールの洗練
19.7 コミットメントの最終決定
19.8 終わりに
第20章 スプリントの実施
20.1 概要
タイミング
参加者
プロセス
20.2 スプリントプランニング
20.3 フローの管理
並列作業とスウォーミング
どの作業から着手すべきか
どのようにタスクを計画すべきか
どの作業を完了させるべきか
誰が作業をするのか
20.4 デイリースクラム
20.5 タスクの実行（技術的プラクティス）
20.6 コミュニケーション
タスクボード
スプリントバーンダウンチャート
スプリントバーンアップチャート
20.7 終わりに
第21章 スプリントレビュー
21.1 概要
21.2 参加者
21.3 事前準備
誰を招待するのかを決める
スケジュールを調整する
スプリントの成果が完成したことを確認する
デモを準備する
誰が何をするかを決める
21.4 アプローチ
概要
デモ
議論
適応
21.5 スプリントレビューの問題
サインオフ
参加者の不在
大規模プロジェクト
21.6 終わりに
第22章 スプリントレトロスペクティブ
22.1 概要
22.2 参加者
22.3 事前準備
フォーカスを定義する
エクササイズを選択する
客観的データを収集する
レトロスペクティブを構成する
22.4 アプローチ
雰囲気づくりをする
コンテキストを共有する
インサイトを特定する
アクションを決定する
レトロスペクティブを終了する
22.5 その後のフォロー
22.6 スプリントレトロスペクティブの問題点
22.7 終わりに
第23章 未来へ
23.1 最終形態などない
23.2 独自の道を探し出せ
23.3 ベストプラクティスを共有せよ
23.4 スクラムを使って、進むべき道を探し出せ
23.5 歩を止めるな！
補遺
用語集
概要
用語定義
参考資料
訳者あとがき
謝辞
索引