プラクティス名（別名）
スプリント0 （イテレーションゼロ）
プラクティスの目的・狙い
- アジャイル開発のマインドセットを浸透させる（重要!）
- チームメンバーと関係者の前提認識を揃え、開発方針と体制を定める
- スプリントを開始できるよう環境を整える
どんな時に使うか
- 新規開発などで前提/目的/経緯といった文脈が共有できていない時
- チームや顧客の中に新メンバーやアジャイル未経験者がいる時
実施手順
- スプリント1に入る前に一定期間を設けて実施する
- 方針検討は原則チーム全員参加で行う（ステークホルダーは必要に応じて）
- 前提条件や開発方針は明文化し、いつでも参照できる場所に掲載する（適宜更新）
- 環境整備やツール設定を含め、スプリント開始に向けて必要な準備を済ませる
（内容は相互に関連するため、上から順にというより重要なものから検討する）
| 実施事項 | 具体的な検討内容・確認内容（例） |
|---|---|
| チームビルディング | 要員アサイン、自己紹介、スキル可視化、ロール確定、体制図、チームのミッション共有 |
| プロダクト定義 | ビジョンの共有、市場環境分析、プロダクトゴール決定 |
| マインドセット | アジャイル宣言＆スクラムガイドの理解 |
| 基礎教育 | 業務知識共有/技術知識共有/プラクティス説明/PO教育/DEV教育 |
| 開発方針 | 何を優先するか？（トレードオフ）、価値基準、判断基準 |
| 開発スコープ | どこまでを開発範囲とするか？ （何をする/しない） |
| ステークホルダー | 誰とどの程度コミュケーションをとるか？ |
| チーム運営方針 | スプリント期間、定例会議と参加者、連絡方法、報告形式、使用ツール、採用プラクティス、ワーキングアグリーメント作成、Wiki作成 |
| ユーザ要求一覧化 | PBLの第一版作成、ユーザヒアリング、優先順位付け |
| 作業量見積もり | SP見積＆集計、必要な期間とリソース |
| 大まかなリリース計画 | いつ頃、何をリリースできそうか？、マイルストーン |
| リスクの洗い出し | 想定される主なリスクとその影響・対策 |
| 品質基準 | 完成の定義、非機能要件、作成対象ドキュメント、測定メトリクス、コーディング規約、関連法規 |
| 技術検証 | アーキテクチャ策定、技術調査、PoC、ツール選定 |
| 環境準備・ツール設定 | 開発環境等の構築、設定、申請、ID提供、タスクボード準備、自動テストツール、CI/CDツール |
| ブランチ戦略 | リポジトリ運用ルール |
| 関係者合意 | ステークホルダーと上記方針を共有＆合意 |
アレンジ例
- 開発方針を明確化するためインセプションデッキをチームで作成する
- PBL第一版作成のためユーザーストーリーマッピングを実施する
- メンバーにも他にやるべきタスクがないか挙げてもらう
アンチパターン
- POが検討に参加していない（チームが文書化したものを後でレビューするなど）
- スプリント0を完璧にやり遂げようとして、なかなかスプリント1に入れない（本末転倒）
参考情報
スプリント0でやるべきことはryuzeeさんが以下の記事で全て言い尽くしてくれています。より詳細に知りたい方にオススメです。
こぼれ話（私的コメント）
「スプリント0にどの程度の期間が必要か？」
よく聞かれる質問です。案件規模や難易度、メンバーの習熟度、顧客との関係性などによっても変わってくるため一概には答えられないのですが、目安として「スプリント1で走り出すのに困らない程度」に準備ができていればOKと伝えています。正直、時間はいくらあっても足らないので、個人的には最大限の日程確保をオススメしたいところですが、期間中に7割消化できればいいかな、ぐらいの感覚で次に進めています。
スプリント0の所要期間を正確に見積もろうとするより、確保できた期間の中で優先度の高いものからできるだけ消化する、という考え方に切り替えた方がいいかもしれません。
チーム全員参加の合宿形式で集中的にやれたら理想的なんだけどなぁ、といつも思いますが、大抵、POが忙しくて実現しません・・・。