英語でスプリントゴールを設定するよう求められたとき、何をどう書けばチーム全員が納得するか迷った経験はないだろうか。
スプリントゴール（Sprint Goal）はスプリント全体の方向性を示す1〜2文の目標だ。ゴール文・成功基準・前提条件・リスクの4つの構成要素を押さえれば、英語でも問題なく書ける。
この記事では、英語スプリントゴールに必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のスプリント計画で活用できる。
スプリントゴールに必要な4つの構成要素
スプリントゴール（Sprint Goal）はスクラムガイドで定義された「スプリントの唯一の目標」だ。バックログのタスクリストとは異なり、「このスプリントで何を達成するか」というビジネス価値を1〜2文で表現する。以下の4つが実務で使いやすい構成要素になる。
- ゴール文（Goal Statement）
- 成功基準（Success Criteria）
- 前提条件・制約（Assumptions & Constraints）
- リスク・依存関係（Risks & Dependencies）
スプリントゴールとスプリントバックログの違い
スプリントバックログはスプリントで実施するタスクの一覧だ。スプリントゴールはそのタスク群が目指す「なぜ」の部分を表す。ゴールが明確なチームはスプリント中に予期せぬ変更が生じても、ゴールに照らして取捨選択の判断ができる。
なぜ英語で書くのか
グローバルチームではPO・スクラムマスター・開発者が異なる拠点にいる。英語でスプリントゴールを書くことで、スプリント計画会議からレビューまで全員が同じゴールを共有できる。
スプリント計画との連携は英語スプリント計画書の書き方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
ゴール文
| 項目 | 内容 |
|---|---|
| スプリント番号 | （例：Sprint 44） |
| スプリント期間 | （例：2026年9月1日〜9月12日） |
| スプリントゴール | （例：Apple Pay・Google Payの決済統合を完了し、モバイルユーザーがカード番号入力なしでチェックアウトできるようにする） |
| ゴールの背景 | （例：モバイル決済の離脱率12%を改善するため、今スプリントで決済UXの主要ボトルネックを解消する） |
| ゴールの種別 | （例：新機能リリース） |
ゴール文の3要素：
- 何を（What）： （例：Apple Pay・Google Payの決済統合）
- 誰のために（For whom）： （例：モバイルユーザー）
- なぜ（Why）： （例：カード番号入力の手間をなくし、離脱率を改善するため）
成功基準
| No. | 成功基準 | 測定方法 |
|---|---|---|
| 1 | （例：Apple PayとGoogle Payで決済が完了できる） | （例：ステージング環境でのE2Eテスト合格） |
| 2 | （例：既存のクレジットカード決済フローに影響がない） | （例：リグレッションテスト全件合格） |
| 3 | （例：決済エラー時に適切なメッセージが表示される） | （例：エラーシナリオのUATサインオフ） |
| 4 | （例：レスポンスタイムが現状（平均300ms）以下を維持する） | （例：負荷テストでP95 500ms以内） |
完了の定義（DoD）との関係： 成功基準はこのスプリント固有の達成条件。DoDはチームが毎スプリント守る品質基準。両方を満たして初めて「完了」とする。
前提条件・制約
| 項目 | 内容 |
|---|---|
| 前提条件 | （例：Apple Pay APIキーの取得が完了している / ステージング環境が利用可能） |
| 技術的制約 | （例：既存の決済SDKのバージョンを変更しない） |
| スコープ外 | （例：Google Payの日本以外のリージョン対応は含まない） |
| 工数制約 | （例：チームの総キャパシティは60pt。QAエンジニアが週3日稼働） |
リスク・依存関係
| リスク・依存 | 内容 | 対応策 |
|---|---|---|
| （例：Apple Pay API仕様変更） | （例：Apple Developer Docsが最新版に更新されている可能性） | （例：スプリント開始前にAPIバージョンを確認し、変更があれば見積もりを再調整） |
| （例：QAリソース不足） | （例：QAが週3日しか稼働できないため、テストの順序が重要） | （例：優先度高のE2Eテストを週前半に集中させる） |
| （例：PAY-108への依存） | （例：Apple Pay APIキー取得（PAY-108）が未完了の場合ブロックされる） | （例：PAY-108はスプリント開始時点で完了済みであることをPOが確認） |
英語版テンプレート（コピペOK）
Goal Statement
| Item | Details |
|---|---|
| Sprint Number | (e.g., Sprint 44) |
| Sprint Period | (e.g., September 1–12, 2026) |
| Sprint Goal | (e.g., Complete Apple Pay and Google Pay payment integration so that mobile users can check out without entering card details.) |
| Background | (e.g., To reduce the 12% mobile checkout drop-off rate, this sprint eliminates the primary UX bottleneck in the payment flow.) |
| Goal Type | (e.g., New Feature Release) |
The 3 elements of a Sprint Goal:
- What: (e.g., Apple Pay and Google Pay payment integration)
- For whom: (e.g., Mobile users)
- Why: (e.g., To eliminate card entry friction and reduce drop-off rate)
Success Criteria
| No. | Success Criterion | How to Measure |
|---|---|---|
| 1 | (e.g., Users can complete payment via Apple Pay and Google Pay.) | (e.g., E2E tests pass in staging environment.) |
| 2 | (e.g., Existing credit card checkout flow is not affected.) | (e.g., All regression tests pass.) |
| 3 | (e.g., Appropriate error messages are displayed when payment fails.) | (e.g., Error scenario UAT sign-off.) |
| 4 | (e.g., Response time stays at or below current baseline (avg. 300ms).) | (e.g., P95 under 500ms in load test.) |
Relationship to Definition of Done (DoD): Success criteria are sprint-specific achievement conditions. DoD is the team’s standing quality standard applied every sprint. Both must be met for a story to be “Done.”
Assumptions & Constraints
| Item | Details |
|---|---|
| Assumptions | (e.g., Apple Pay API key provisioning is complete / Staging environment is available.) |
| Technical Constraints | (e.g., No changes to the existing payment SDK version.) |
| Out of Scope | (e.g., Google Pay support outside Japan is not included.) |
| Capacity Constraints | (e.g., Total team capacity is 60 pts. QA engineer available 3 days/week.) |
Risks & Dependencies
| Risk / Dependency | Details | Mitigation |
|---|---|---|
| (e.g., Apple Pay API spec change) | (e.g., Apple Developer Docs may have been updated to a new version.) | (e.g., Confirm API version before sprint start; re-estimate if changed.) |
| (e.g., QA resource constraint) | (e.g., QA is only available 3 days/week, making test sequencing critical.) | (e.g., Front-load high-priority E2E tests to the first half of the sprint.) |
| (e.g., Dependency on PAY-108) | (e.g., Blocked if Apple Pay API key provisioning (PAY-108) is incomplete.) | (e.g., PO confirms PAY-108 is done before sprint kickoff.) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
ゴール文の書き方（so that 構文）
スプリントゴールは「何を達成するか」だけでなく「なぜそれが重要か」まで含める。「so that（〜するために）」を使うことで、チームがスプリント中に判断を迫られたとき、ゴールに立ち返れる。
| 日本語 | 英語 |
|---|---|
| 〇〇を完成させ、〇〇できるようにする | Complete [deliverable] so that [user benefit]. |
| 〇〇を改善し、〇〇できるようにする | Improve [area] so that [stakeholder] can [outcome]. |
| 〇〇を解決し、〇〇が可能になる | Resolve [problem] so that [capability is enabled]. |
悪い例（NGパターン）：
“Implement Apple Pay and Google Pay.” → タスクを列挙しているだけで、ビジネス価値が見えない。
良い例（OKパターン）：
“Complete Apple Pay and Google Pay integration so that mobile users can check out without entering card details.”
成功基準の書き方（測定可能な条件）
「うまく動く」「品質が高い」では検証できない。「E2Eテスト全件合格」「P95が500ms以内」のように数値・テスト可否で定義する。
| 日本語 | 英語 |
|---|---|
| 〇〇のE2Eテストが全件合格する | All E2E tests for [feature] pass. |
| 〇〇のエラーレートが〇%以下である | Error rate for [feature] is below X%. |
| 〇〇がQAサインオフ済みである | [Feature] has received QA sign-off. |
バックログリファインメントとの連携は英語バックログリファインメントの書き方でも確認してほしい。
スプリントゴールでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
スプリントゴールの基本用語
| 日本語 | 英語 |
|---|---|
| スプリントゴール | Sprint Goal |
| 成功基準 | Success Criteria |
| 完了の定義 | Definition of Done (DoD) |
| スコープ外 | Out of Scope |
| 前提条件 | Assumptions |
| 依存関係 | Dependencies |
| キャパシティ | Capacity |
| スプリント計画 | Sprint Planning |
| スプリントレビュー | Sprint Review |
| ゴール達成 | Goal Achievement / Goal Met |
スプリント計画会議でのフレーズ
| 日本語 | 英語 |
|---|---|
| このスプリントのゴールを確認しましょう | Let’s align on the sprint goal for this sprint. |
| このゴールはスプリント内で達成できますか？ | Is this goal achievable within the sprint? |
| 成功基準を明確にしましょう | Let’s clarify the success criteria. |
| このリスクにどう対処しますか？ | How do we plan to address this risk? |
| ゴールを達成するためのキャパシティは十分ですか？ | Do we have enough capacity to meet this goal? |
スプリントレビューとの連携は英語スプリントレビューの書き方でも確認してほしい。
スプリントゴールの達成状況をバーンダウンで可視化する方法は英語スプリントバーンダウンレポートの書き方でも確認してほしい。ゴール達成率とベロシティをセットで記録することで次スプリントの計画精度が上がる。
日報・週報でスプリントゴールへの貢献を示す際は英語日報・週報の書き方の「本日の作業」テンプレートも参考にしてほしい。チケットIDとゴールの紐付けを明示することでチームの方向性が揃う。
スプリントゴールを達成するためのキャパシティ配分は英語スプリントキャパシティ計画書の書き方でも確認してほしい。スパイク用確保ポイントをゴール達成に必要なバックログポイントと並べることで計画の実現可能性を数字で示せる。
スプリントゴールを設定する前にスパイクで不確実性を除去する方法は英語テクニカルスパイクの書き方でも確認してほしい。タイムボックスと成果物を明確にすることでスパイク終了後すぐにゴールの成功基準を更新できる。
スプリントゴールの達成度をレトロスペクティブで振り返る際は英語スプリントレトロスペクティブの書き方のKPTテンプレートも参考にしてほしい。ゴール未達の原因をProblemに記録し、次スプリントのTryに落とし込むことで継続的改善につながる。
まとめ：英語スプリントゴールは4つのセクションで完成する
英語スプリントゴールに必要な構成要素を整理した。
- ゴール文は「何を・誰のために・なぜ」の3要素で書き、so that 構文でビジネス価値まで表現する
- 成功基準はテスト可否・数値で定義し、スプリント終了時に「達成か否か」を判断できる状態にする
- 前提条件・制約はスコープ外と工数制約を明示し、スプリント中の範囲外の要求を防ぐ
- リスク・依存関係は対応策とセットで記録し、スプリント開始前に解消できるものは解消する
テンプレートをコピーして、まず「so that」の部分から書き始めてほしい。この1フレーズが決まれば、成功基準とスコープの議論が自然と収束する。
コメント