英語でスプリント計画書を書くよう求められたとき、何をどの順序で記録すればいいか迷った経験はないだろうか。
スプリント計画書（Sprint Planning Document）はスプリントの目標・スコープ・タスク割り当てを明確にする文書だ。スプリントゴール・バックログ選定・タスク分解・キャパシティ確認の4つの構成要素さえ押さえれば、英語でも問題なく進行できる。
この記事では、英語スプリント計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のスプリント計画ミーティングで活用できる。
スプリント計画書に必要な4つの構成要素
スプリント計画書（Sprint Planning Document）はスクラムチームがスプリント開始時に作成するドキュメントだ。Scrum Guideの定義に基づき、以下の4つが実務で使いやすい構成要素になる。
- スプリント概要（Sprint Overview）
- スプリントゴール（Sprint Goal）
- バックログ選定（Backlog Selection）
- キャパシティ・タスク分解（Capacity & Task Breakdown）
スプリント計画書とスプリントバックログの違い
スプリントバックログはチケット一覧だ。スプリント計画書はそれに加えて「なぜこのスプリントで何を達成するのか」というゴールと判断根拠を記録する。ステークホルダーや新メンバーが後から読んでも意図がわかる点が大きな違いだ。
なぜ英語で書くのか
グローバルチームでは、PO・スクラムマスター・開発メンバーが異なるタイムゾーンで作業する。英語で計画書を残すことで、非同期でもスプリントの目的と優先度が全員に伝わり、認識のズレを防げる。
技術ロードマップとの連携は英語技術ロードマップの書き方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
スプリント概要
| 項目 | 内容 |
|---|---|
| スプリント番号 | （例：Sprint 42） |
| 期間 | （例：2026年8月3日〜2026年8月14日） |
| スクラムマスター | （例：田中） |
| プロダクトオーナー | （例：鈴木） |
| 参加チーム | （例：バックエンド3名・フロントエンド2名） |
| ストーリーポイント上限 | （例：40pt） |
スプリントゴール
| 項目 | 内容 |
|---|---|
| スプリントゴール | （例：決済フローのレスポンスタイムを50%改善し、ユーザーの離脱率を下げる） |
| 成功基準 | （例：決済APIのP95レスポンスタイムが現状の800msから400ms以下になる） |
| ゴール設定の背景 | （例：先週のユーザーインタビューで決済画面での離脱が報告された） |
バックログ選定
| チケットID | タイトル | ストーリーポイント | 担当者 | 優先度 |
|---|---|---|---|---|
| （例：PAY-101） | （例：決済APIのクエリを最適化する） | （例：8） | （例：田中） | （例：高） |
| （例：PAY-102） | （例：不要なAPIコールをキャッシュで削減する） | （例：5） | （例：佐藤） | （例：高） |
| （例：PAY-103） | （例：決済フローのE2Eテストを追加する） | （例：3） | （例：鈴木） | （例：中） |
| 合計 | （例：16/40pt） |
選定基準： スプリントゴールへの貢献度 → 技術的依存関係 → ビジネス優先度
キャパシティ・タスク分解
| メンバー | 稼働日数 | 稼働率 | 担当チケット |
|---|---|---|---|
| （例：田中） | （例：10日） | （例：80%） | （例：PAY-101） |
| （例：佐藤） | （例：10日） | （例：100%） | （例：PAY-102） |
| （例：鈴木） | （例：8日） | （例：70%） | （例：PAY-103） |
タスク分解（PAY-101の例）：
| タスク | 推定時間 |
|---|---|
| （例：現状のクエリプランを分析する） | （例：2h） |
| （例：インデックスを追加・最適化する） | （例：4h） |
| （例：負荷テストで効果を確認する） | （例：2h） |
英語版テンプレート（コピペOK）
Sprint Overview
| Item | Details |
|---|---|
| Sprint Number | (e.g., Sprint 42) |
| Duration | (e.g., August 3 – August 14, 2026) |
| Scrum Master | (e.g., Tanaka) |
| Product Owner | (e.g., Suzuki) |
| Team | (e.g., 3 Backend / 2 Frontend) |
| Story Point Capacity | (e.g., 40 pts) |
Sprint Goal
| Item | Details |
|---|---|
| Sprint Goal | (e.g., Reduce checkout flow response time by 50% to decrease user drop-off.) |
| Success Criteria | (e.g., Payment API P95 response time drops from 800ms to under 400ms.) |
| Background | (e.g., User interviews last week flagged drop-off on the checkout screen.) |
Backlog Selection
| Ticket ID | Title | Story Points | Assignee | Priority |
|---|---|---|---|---|
| (e.g., PAY-101) | (e.g., Optimize payment API queries) | (e.g., 8) | (e.g., Tanaka) | (e.g., High) |
| (e.g., PAY-102) | (e.g., Reduce redundant API calls with caching) | (e.g., 5) | (e.g., Sato) | (e.g., High) |
| (e.g., PAY-103) | (e.g., Add E2E tests for checkout flow) | (e.g., 3) | (e.g., Suzuki) | (e.g., Medium) |
| Total | (e.g., 16 / 40 pts) |
Selection criteria: Contribution to Sprint Goal → Technical dependencies → Business priority
Capacity & Task Breakdown
| Member | Working Days | Availability | Assigned Ticket |
|---|---|---|---|
| (e.g., Tanaka) | (e.g., 10 days) | (e.g., 80%) | (e.g., PAY-101) |
| (e.g., Sato) | (e.g., 10 days) | (e.g., 100%) | (e.g., PAY-102) |
| (e.g., Suzuki) | (e.g., 8 days) | (e.g., 70%) | (e.g., PAY-103) |
Task Breakdown (PAY-101 example):
| Task | Estimated Time |
|---|---|
| (e.g., Analyze current query plan) | (e.g., 2h) |
| (e.g., Add and optimize indexes) | (e.g., 4h) |
| (e.g., Validate improvements via load testing) | (e.g., 2h) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
スプリントゴールの書き方（成果ベースで書く）
スプリントゴールは「何を作るか」ではなく「何を達成するか」で書く。「決済APIを改修する」ではなく「決済レスポンスタイムを50%改善する」のように、ビジネス上の成果を明示する。
| 日本語 | 英語 |
|---|---|
| ユーザーの離脱率を下げる | Reduce user drop-off rate. |
| 新機能をリリースして〇〇を改善する | Release [feature] to improve [outcome]. |
| 技術的負債を解消してデプロイ頻度を上げる | Pay down tech debt to increase deployment frequency. |
| 〇〇のパフォーマンスを〇%向上させる | Improve [component] performance by X%. |
キャパシティの書き方（稼働率を正直に書く）
稼働率は100%にしない。会議・レビュー・1on1・突発対応を差し引くと実際の開発稼働は70〜80%が現実的だ。「Available capacity」として実稼働時間を計算してから積み上げる。
| 日本語 | 英語 |
|---|---|
| 今スプリントは〇日稼働します | I’m available for X days this sprint. |
| 有給取得のため稼働率が下がります | My availability is reduced due to planned leave. |
| 実稼働キャパシティは〇ptです | Our effective capacity is X story points. |
| リスクバッファとして〇ptを確保します | We’re reserving X pts as a risk buffer. |
テクニカルデット管理との連携は英語テクニカルデット登録の書き方でも参考にしてほしい。
スプリント計画ミーティングでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
スプリント計画の基本用語
| 日本語 | 英語 |
|---|---|
| スプリントゴール | Sprint Goal |
| プロダクトバックログ | Product Backlog |
| スプリントバックログ | Sprint Backlog |
| ストーリーポイント | Story Points |
| ベロシティ | Velocity |
| キャパシティ | Capacity |
| タスク分解 | Task Breakdown |
| 完了の定義 | Definition of Done (DoD) |
| スプリントレビュー | Sprint Review |
| リファインメント | Backlog Refinement |
スプリント計画ミーティングでのフレーズ
| 日本語 | 英語 |
|---|---|
| 今スプリントのゴールを確認しましょう | Let’s align on the Sprint Goal for this sprint. |
| このチケットをスプリントに入れる理由を教えてください | Can you explain why this ticket is included in the sprint? |
| このチケットは今スプリントに収まりますか？ | Can this ticket fit within the sprint? |
| ストーリーポイントを見積もってください | Please estimate the story points for this. |
| キャパシティを超えているので、このチケットは次のスプリントに回します | This exceeds our capacity, so we’ll move this to the next sprint. |
| 完了の定義を確認しておきましょう | Let’s review our Definition of Done. |
アーキテクチャ設計との連携は英語アーキテクチャ設計書の書き方でも参考にしてほしい。
フラグ削除タスクをスプリントに組み込む方法は、英語フィーチャーフラグ管理表の書き方でも参考になるので確認してほしい。
スプリントを円滑に進めるにはチームのワーキングアグリーメントが前提になる。英語チームチャーターの書き方でチームルールの英語テンプレートも確認してほしい。
まとめ：英語スプリント計画書は4つのセクションで完成する
英語スプリント計画書に必要な構成要素を整理した。
- スプリントゴールは「何を作るか」ではなく「何を達成するか」で書き、成功基準を数値で示す
- バックログ選定は「ゴールへの貢献度→技術依存関係→ビジネス優先度」の順で判断する
- キャパシティは70〜80%の稼働率で計算し、リスクバッファを必ず確保する
- タスクはチケット単位で分解し、1タスクを4時間以内に収めると進捗が見えやすい
テンプレートをコピーして、まず「スプリントゴール」と「成功基準」から書き始めてほしい。この2行が固まれば、バックログ選定の判断軸が自然と決まる。
コメント