Scrum（スクラム）とは、Project（プロジェクト）の現状を把握する為のフレームワークである。
ビズリーチ社におけるScrumの正しい理解を促進する目的で本ドキュメントを作成し、公開する。
文責：スクラム推進グループ（貝瀬、江端）
- Project（プロジェクト）とは、定めた目的を実現する為の「活動」
- Product（プロダクト）とは、対象に対して提供しようとしている「仮説」
組織論と集団心理学を基礎としている。Projectは、組織的かつ集団で遂行する事が大半なので、この学問を引用している。
Scrumが具体的に参考にしてる組織論は複数あるが、主に「Team-based organizations」の思想が、Scrumには強く反映されている。中央集権型モデルと重要視しているコトが異なっている。
アメリカの心理学者であるGeorge Armitage Miller（ジョージ・A. ミラー）の研究を引用している。認知心理学の先駆者でもあり、Scrumは、認知心理学の誕生と評される「プランと行動の構造」に基づいている。George Armitage Millerは、短期記憶の容量が7±2であることを発見した事で有名。言語学、計算言語学、自然言語処理、オントロジーなどの分野でも著名である。
Scrumは、基礎となる学問から導き出した重要とする「3つの状態」を定義している。それは、Transparence（透明性）、Inspect（検証）、Adapt（適応）である。
正しい情報が、一箇所に集まっており、次の行動が誘発され続けている状態。
- 情報には、消費期限があり、この「正しい情報」とは、現時点での情報として正しいと評価した情報のこと
- 情報を確認できるだけでは、Transparenceではない
- 次の行動が誘発され続けなければならない
定めた目的と現場との差分（ギャップ）を把握し続けている状態。
- Projectで必要とする定めた目的と現場との差分が把握できるだけでは、Inspectではない
- 定めた目的は、1つとは限らない。複数ある場合が多い
- 差分は、常に把握し続けなければならない
定めた目的と現場との差分を埋める為に活動し続けている状態。
- 狙いもなく闇雲に活動しているのは、Adaptではない
- 定めた目的と現場との差分を埋める為の「戦略」に基づいて、行動し続けなければならない
Scrumでは、Role（役割）を3つ定めている。
- Product Owner（プロダクトオーナー）
- Scrum Master（スクラムマスター）
- Team（チーム）
TeamとScrum Team（スクラムチーム）を明確に異なる集団であると定義している。
Product Ownerは、Scrum Teamの「ROI（投資対効果）」を最大化する責任がある。
基本、Project内の制約に基づいて、複雑性をコントロールするなどし、ROIを最大化する戦略立案と戦略に基づくTeam支援を行う。Invester（投資家）とは異なる役割。
ROI最大化の戦略に基づき、Product Backlog（要件や技術的な負債であるUndoneなど）の優先順位を決める。Product Ownerは、すべての要件をProduct Backlogで管理する。Product Backlogにない要件をTeamに依頼することはできない。Stakeholderからの依頼が発生した場合も、Product OwnerはProduct Backlogを通じて、Teamへ依頼する。
Product Ownerは Product Manager（プロダクトマネージャー）が担当することが多いが、上記の責任と役割を果たすことができれば職種に定めはない。
参考：Product ManagerのJob Description（職務記述書）
Teamは、Scrum Team の「生産性」を最大化する責任がある。Development Team（開発チーム）と表現される事が多い。
Teamは、サービスやProductを開発する「生産性」を向上し続けなければならない。単にサービスやProductを開発するだけの役割ではない。
Teamは、開発すべき要件を必ずProduct Backlogから取得する。Product Backlogにない要件を開発してはいけない。Stakeholderからの依頼が発生した場合も、TeamはProduct Ownerにエスカレーションし、Product Backlogを通じて、開発の要件と優先順位を理解する。
Teamには、上記の責任と役割を果たすために必要なすべての職種が含まれるが、エンジニアやデザイナーが含まれることが多い。
Scrum Masterは、Scrum Teamの環境や活動を改善し「目的実現の確率」を最大化する責任がある。
基本、Projectを通じて、Impediment（活動における妨害や障害、課題など）を発見し、組織や環境、活動スタイルやツール等を改善し、目的実現の確率を最大化する戦略立案と戦略に基づくTeam支援を行う。Project Manager（プロジェクトマネージャー）とは異なる役割。
改善戦略に基づき、Impedimentの優先順位を決める。
参考：Scrum MasterのJob Description
Scrum Teamとは、Product Owner、Scrum Master、Teamの3つの役割で構成されている集団のこと。
- Teamと異なり人数制限はない
- 他の役割は全てStakeholder（利害関係者）と位置付けて捉えて、Scrum Teamは協業する
Ceremonyとは、Scrumを実践する中で Scrum Teamが行う5つの打合せのこと。Scrum Event（スクラムイベント）や Scrum Meeting（スクラムミーティング）と表現されるようになりつつある。
- Sprint Planning（スプリントプランニング）
- Daily Scrum（デイリースクラム）
- Product Backlog Refinement（プロダクトバックログリファインメント）
- Sprint Review（スプリントレビュー）
- Sprint Retrospective（スプリントレトロスペクティブ）
上記以外に、PO会議などで実施する、事業部内の重要な意思決定やチーム横断の優先順位調整もあるが、これらはオプションである。
Scrum Teamが、Sprint（短期間）の計画または再計画を行うCeremony。
- Product BacklogのProduct Backlog Item（プロダクトバックログアイテム）のうち優先順位の高いものから実現に必要な設計を行い、必要なSprint Backlog Item（スプリントバックログアイテム）を洗い出す
- そのSprintで、「期待するVelocity（ベロシティ）」を確定する
- Product Backlog Refinementで、Product Backlogの優先順位が高いProduct Backlog Itemを、Sprint Planning可能な状態にしておく
- Product Backlog RefinementとSprint Planningまでの間に追加されたProduct Backlog Itemは、例外として対応する
- Sprint Backlog Itemは、「30分単位」で管理する
- 30分単位で管理できなければ、Sprint中に、Team で助けあえない可能性を高め、Sprintが未達になる等、計画がブレるリスクが高まるので避けるべき
- Sprint Backlog Itemを細分化し、30分枠の箱にSprint Backlog Itemを入れるイメージを持つと実現し易い
- 1週間のSprintの場合、実施時間は「4時間」
- 4時間以内に終了することが望ましいが、最初は、時間を延長してでも徹底的に実施すべきである（時間より内容を優先する）
- Product Backlog Refinementで、Product BacklogをSprint Planning可能な状態にしておかないと、Sprint Planningの実施時間が長くなる
2つの目的があるCeremony。
- Sprint Planningで計画した通りに推進しているのかを確認し、Impedimentの有無を把握する
- 前回のSprint RetrospectiveでCommitment（コミットメント）した改善アクションを実施しているのか、効果が出ているのかを確認する
- 基本的な質問のテンプレートは、以下の3つの質問
- 前回のDaily Scrumから、今回のDaily Scrumまで何を行いましたか？
- 今回のDaily Scrumまで何を実施する予定ですか？
- 困っている事や課題、Impedimentはありませんか？
- 質問に回答しながら、Sprint Backlog Itemのステータスを更新する
- Teamの成熟度に合わせて、質問内容を変更したり、質問を追加しても良い
- Sprintの長さを問わず、実施時間は「15分」
- 必ず15以内に終了する（内容より時間を優先する）
Scrum Teamが、当該Sprintより先の中長期の計画または再計画を行うCeremony。
- 少なくとも、2~3Sprint先のProduct Backlog Itemの追加や修正、見積り、Product Backlogの優先順位を更新する
- 可能なら、2~3Sprintよりも先まで、Product Backlog Itemの追加や修正、見積り、Product Backlogの優先順位まで更新できると更に良い
- Product Backlog Itemの見積りは、「プランニングポーカー」を使って、相対見積りで見積る
- Product Backlog Itemの見積る対象は「複雑度」である。決して、作業時間ではない
- 1週間のSprintの場合、実施時間は、「1時間」
- 遅くとも2時間以内に終了する（内容より時間を優先する）
2つの目的がある Ceremony。
- Scrum Teamが、Sprint Planningで計画した内容が、「Productで実現」できているのかを確認し、Velocityの「実績」を算出する
- Scrum Teamが、現状の実Productを使いながら、より良くする為のアイデアを出したり、議論する
- Productは、Acceptance Criteria（受入基準）と Done（技術品質）を満たしていないければ、Accepted（完了）とはならない
- Product Backlog Itemのステータスは、AcceptedかNot Acceptedしかない
- AcceptedとなったProduct Backlog Itemは、ステータスが Acceptedとなる
- Not AcceptedとなったProduct Backlog Itemは、ステータスを更新せず、次のSprint以降で予定しているProduct Backlog Itemと合わせて優先順位を再検討する
- 1週間のSprintの場合、実施時間は、「30分」
- 遅くとも1時間以内に終了する（内容より時間を優先する）
Teamが、生産性を向上する目的のために、次のSprintで「実施する具体的な改善アクションを Commitment（コミットメント）」するCeremony。
- Sprintでの事象を分析して、改善課題を特定する
- 思い込みから改善課題を設定してはならない
- 前までのSprintでCommitmentした改善アクションの効果も分析しなければならない
- Commitmentした改善アクションは、Sprint単位で積み上げ、増やし続ける
- 1週間のSprintの場合、実施時間は、「30分」
- 遅くとも1時間以内に終了する（内容より時間を優先する）
Artefact（アーティファクト）とは、Scrumを実践する中でScrum Teamが作成、管理する、5つの作成物。
- Product Backlog（プロダクトバックログ）
- Sprint Backlog（スプリントバックログ）
- Impediment List（妨害リスト）
- Done / Definition of Done（Doneの定義）
- Potentially Shippable Product Increment（出荷可能なプロダクト単位）
上記以外に、Market（マーケット）を定義したり、Marketの課題を管理する作成物として、Lean CanvasやIssue Map 等があるが、これらはオプションである。
5つの目的があるArtefact。
- Scrum Teamが、取り扱うProduct Backlog Item（要件）の一覧
- Scrum Team内で、Product Backlog Itemを軸に、不明点を確認や特定する
- Product Ownerが、ROIを最大化する為の「戦略」を明らかにする
- その為に、Product Backlog Itemの優先順位を明らかにする
- Product Ownerが、ROIを最大化する為に、Acceptance Criteria（受け入れ基準）を明確にする
- その為に、1つ1つのProduct Backlog Itemのスコープをコントロールする
- Teamが、Productで実現する「期待」、実現できた「実績」を管理する
- その為に、Velocityを把握する
- Scrum Team が、Team のVelocityに基づいて、中長期の計画の見通しを確認し、再計画した内容を管理する
不具合やバグについても必ずProduct Backlogで一元管理し、優先順位に基づいて開発する。
- Product Backlog Itemの見積る対象は、要件の「複雑度」である
- 理由は、確率高く実現できるか否かを把握したいため
- Product Backlog Item1つあたりの見積りは、最大「5」までに抑える
- 5を超えるサイズは必ず分割する
- 3以内でコントロールできるようになるのが望ましい
- 管理するツールは、Atlassian社の「JIRA」とする
5つの目的があるArtefact。
- Teamが、Sprintで実行する戦略を明らかにする
- Teamが、Sprintで実行するタスク（作業）を明らかにする
- 実行するタスクは、Scrum Teamが合意したProduct Backlog Itemのみ
- Teamが、Sprintにおけるタスクのステータスを管理する
- タスクの状態「実行前、実行中、完了」を明らかにする
- Sprintにおいて、Teamが計画通り実行できているのか、協力しているのか、問題を放置していないのかを明らかにする
- Done/Undoneを明らかにする
- 管理するツールは、アナログツールの「ホワイトボードや模造紙」と「付箋」とする
3つの目的があるArtefact。
- Projectにおける、Impediment（活動における妨害や障害、課題など）を明らかにする
- 本ガイドラインから逸脱したルールで運営されているScrumなどもImpedimentとして取り扱わなければならない
- Scrum Masterが、Scrum Teamの目的実現の確率を最大化する為の「戦略」を明らかにする
- その為に、「取り扱うImpedimentの優先順位」を明らかにする
- Scrum Teamが、Projectの改善実績、改善中、未着手課題を明らかにする
- 管理するツールは、Atlassian社の「JIRA」とする。
2つの目的があるArtefact。
- Scrum Teamとして、Productをリリースする為に、すべき事を管理する
- Done/Undoneを区別して管理し、Productにおけるリスク、Projectにおける「サービス提供社としてのリスク」を明らかにする
- Done とは、Productをリリースする為に、すべき事が出来ているProductの状態のこと
- Doneは、開発手順が「Definition of Done」を最初に構築・実現し、それから要件を開発する
- Undoneとは、Productをリリースする為に、すべき事が出来ていない Productの状態のこと
- Undoneは、開発手順が「要件」を最初に構築・実現し、それから Definition of Done を実現する
Done/Undoneの区別は、作業の順番で決まる。
Teamが、どの要件でもProductをリリースできるよう、要件を開発できるか否かを判断する目的のArtefact。
この実現力が高いTeamが、Technical debt（技術的な負債）が少ない Productを開発、維持できる。世界中のTeamが実現できるよう切磋琢磨して、創意工夫しながら技術力を高めている。
世界中で実現できているTeamはないが、2019年3月末時点では、netflix のチームが、Chaos Engineering（カオスエンジニアリング）に取組むなど、実現に最も近いと評価されている。
Sprint（スプリント）とは短期間のこと。期間を定めるのには6つの目的がある。
- Scrum Teamとして、計画をする期間（短期間）を明らかにする
- Teamとして、短期間の戦略が立案できるようにする
- Velocity（短期の実績）から、戦略を継続的に改善できる
- Product Ownerとして、中長期の戦略が立案できるようにする
- Velocityから、戦略を継続的に改善できる
- Scrum Masterとして、Projectの状況把握と改善戦略が立案できるようにする
- Velocityなどから、中長期の戦略を継続的に改善できる
- Scrum Teamとして、活動を調整し易くする
- 対象となる期間が一定となるため
- Scrum Teamの活動サイクルを明らかにする
- Stakeholderとも調整し易くなる
- Sprintは、「1週間」とする
- 祝日がある場合は、稼働日数を減らして計画、実行する
ビズリーチ社におけるScrumの導入・活用状況を可視化するためのチェックリスト。主にスクラム推進グループのチェッカーが、スクラムマスターやメンターに課題を共有する目的で利用する。
項目の難易度に応じて5段階（+Option）にレベル分けをしているので、レベルNの項目に全てチェックがついたらレベルN+1に進む、といった活用方法が望ましい。
- レベル1:Scrumを最低限導入している
- レベル2:ScrumのArtefactを効率的に運用している
- レベル3:ScrumのCeremonyを効率的に運用している
- レベル4:Scrumを中長期的な目標達成のために活用している
- レベル5:Scrumをビジネスと組織のさらなる成長のために活用している
- Option:Scrumに関する最新のプラクティスを活用している
- Scrum ChecklistーMasterをコピーする
- チェックする日付の列を作り、その時点でできている項目にチェックを入れる
- チェックがつかない項目を参考に、Scrum Masterの目標設定などに活用する
- 次回チェックする日付を決める
- 2に戻る