英語でバックログリファインメントを進めるよう求められたとき、何をどの順序で記録すればいいか迷った経験はないだろうか。
バックログリファインメント（Backlog Refinement）はプロダクトバックログのアイテムを詳細化・見積もり・優先順位付けするセレモニーだ。アイテム詳細化・受け入れ基準・見積もり・優先順位の4つの構成要素さえ押さえれば、英語でも問題なく進行できる。
この記事では、英語バックログリファインメントに必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のリファインメントセッションで活用できる。
バックログリファインメントに必要な4つの構成要素
バックログリファインメント（Backlog Refinement）はProduct Backlog Refinementとも呼ばれ、次のスプリントに向けてバックログアイテムをスプリントで実行できる状態に仕上げるセレモニーだ。以下の4つが実務で使いやすい構成要素になる。
- アイテム詳細化（Item Detail）
- 受け入れ基準（Acceptance Criteria）
- 見積もり（Estimation）
- 優先順位（Prioritization）
バックログリファインメントとスプリント計画の違い
スプリント計画はスプリント開始時に実施し、次スプリントのゴールと選択アイテムを決める。バックログリファインメントはスプリントの途中（一般的にスプリント後半）に実施し、次の次以降のスプリントに向けてバックログを準備する。リファインメントが機能しているほど、スプリント計画がスムーズになる。
なぜ英語で記録するのか
グローバルチームでは、PO・スクラムマスター・開発チームが異なるタイムゾーンで作業する。英語でリファインメントの議論を記録することで、非同期でも「なぜこの要件なのか」「完成の定義はどこか」が全員に伝わる。
受け入れ基準の詳細化は英語スプリント計画書の書き方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
アイテム詳細化
| 項目 | 内容 |
|---|---|
| チケットID | （例：PAY-110） |
| タイトル | （例：決済フローにApple Pay対応を追加する） |
| ユーザーストーリー | （例：モバイルユーザーとして、Apple Payで決済できるようにしたい。なぜなら毎回カード番号を入力する手間を省きたいから。） |
| ビジネス背景 | （例：モバイルからの決済離脱率が12%。Apple Pay対応で離脱を3〜5%改善できると推定している。） |
| スコープ | （例：iOSのSafariとChromeでApple Payが利用できること。Androidは対象外。） |
| スコープ外 | （例：Google Pay・LINE Pay対応は別チケット（PAY-111・PAY-112）に分割済み。） |
| 依存関係 | （例：決済プロバイダーのApple Pay APIキーの発行が前提。インフラチームで対応中（PAY-108）。） |
受け入れ基準
| No. | 受け入れ基準 |
|---|---|
| 1 | （例：iOSデバイスのSafari・ChromeでApple Payボタンが表示される） |
| 2 | （例：Apple Payで決済を完了すると、注文確認画面に遷移する） |
| 3 | （例：Apple Payの決済失敗時に適切なエラーメッセージが表示される） |
| 4 | （例：Apple Pay決済の成功・失敗がサーバーログに記録される） |
| 5 | （例：Android・非対応ブラウザではApple Payボタンが非表示になる） |
完了の定義（DoD）： （例：コードレビュー完了 / テスト合格 / ステージング環境で動作確認済み / ドキュメント更新済み）
見積もり
| 項目 | 内容 |
|---|---|
| ストーリーポイント | （例：13） |
| 見積もり根拠 | （例：Apple Pay JS APIの調査と統合に5〜7日。E2Eテスト作成に2〜3日。合計で想定ベロシティの約1スプリント分。） |
| 不確実性 | （例：決済プロバイダーのAPI仕様が未確認のため、想定より複雑な場合は+5ptになる可能性あり。） |
| 分割可否 | （例：「Safari対応」と「Chrome対応」に分割可能。まずSafariを1スプリントで実施し、Chrome対応を次スプリントに回す選択肢がある。） |
優先順位
| 項目 | 内容 |
|---|---|
| 優先度 | （例：高） |
| 優先度の根拠 | （例：モバイル決済の離脱率改善は今Qの主要KPI。A/Bテストの結果、Apple Payボタンの表示だけで離脱率が8%改善された競合事例あり。） |
| 実施スプリント候補 | （例：Sprint 44（依存関係PAY-108の完了後）） |
| ステークホルダー確認 | （例：PMの山田が優先度「高」を承認済み） |
英語版テンプレート（コピペOK）
Item Detail
| Item | Details |
|---|---|
| Ticket ID | (e.g., PAY-110) |
| Title | (e.g., Add Apple Pay support to checkout flow) |
| User Story | (e.g., As a mobile user, I want to pay with Apple Pay so that I can skip entering my card number manually.) |
| Business Context | (e.g., Mobile checkout drop-off rate is 12%. Adding Apple Pay is estimated to reduce drop-off by 3–5%.) |
| Scope | (e.g., Apple Pay must work on Safari and Chrome on iOS. Android is out of scope.) |
| Out of Scope | (e.g., Google Pay and LINE Pay support have been split into separate tickets (PAY-111, PAY-112).) |
| Dependencies | (e.g., Requires Apple Pay API key from the payment provider. Infra team is handling this (PAY-108).) |
Acceptance Criteria
| No. | Acceptance Criteria |
|---|---|
| 1 | (e.g., The Apple Pay button is displayed on Safari and Chrome on iOS devices.) |
| 2 | (e.g., Completing a payment with Apple Pay redirects the user to the order confirmation screen.) |
| 3 | (e.g., An appropriate error message is shown when Apple Pay payment fails.) |
| 4 | (e.g., Apple Pay payment success and failure events are recorded in server logs.) |
| 5 | (e.g., The Apple Pay button is hidden on Android and unsupported browsers.) |
Definition of Done (DoD): (e.g., Code review complete / All tests passing / Verified in staging environment / Documentation updated)
Estimation
| Item | Details |
|---|---|
| Story Points | (e.g., 13) |
| Rationale | (e.g., Apple Pay JS API research and integration: 5–7 days. E2E test creation: 2–3 days. Total is approximately one sprint at our current velocity.) |
| Uncertainty | (e.g., Payment provider API specs are unconfirmed; complexity may increase by +5 pts if the integration is non-standard.) |
| Split Option | (e.g., Can be split into Safari support and Chrome support. Option to deliver Safari in Sprint 44 and Chrome in Sprint 45.) |
Prioritization
| Item | Details |
|---|---|
| Priority | (e.g., High) |
| Rationale | (e.g., Reducing mobile checkout drop-off is a key KPI this quarter. A competitor case study showed an 8% drop-off reduction from displaying the Apple Pay button alone.) |
| Target Sprint | (e.g., Sprint 44 (after PAY-108 dependency is resolved)) |
| Stakeholder Approval | (e.g., PM Yamada approved as High priority.) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
ユーザーストーリーの書き方（3要素で書く）
ユーザーストーリーは「誰が・何をしたい・なぜか」の3要素で書く。「Apple Pay対応を追加する」ではなく「モバイルユーザーとして、カード番号入力を省くためにApple Payで決済したい」のように書く。
| 日本語 | 英語 |
|---|---|
| 〇〇として〇〇したい | As a [role], I want to [action] |
| なぜなら〇〇だから | so that [benefit]. |
| 〇〇できるようにしてほしい | I need to be able to [action]. |
受け入れ基準の書き方（テスト可能な条件で）
「ユーザーが使いやすい」ではなく「〇〇の場合に〇〇が表示される」のように、テストで検証できる条件として書く。Given-When-Then形式で書くとさらに明確になる。
| 日本語 | 英語 |
|---|---|
| 〇〇の場合、〇〇が表示される | When [condition], [result] is displayed. |
| 〇〇すると、〇〇に遷移する | When [action], the user is redirected to [destination]. |
| 〇〇は〇〇に記録される | [Event] is recorded in [destination]. |
| 〇〇の場合、〇〇は非表示になる | When [condition], [element] is hidden. |
チームの合意事項の管理は英語チームチャーターの書き方でも確認してほしい。
バックログリファインメントでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
バックログリファインメントの基本用語
| 日本語 | 英語 |
|---|---|
| バックログリファインメント | Backlog Refinement |
| ユーザーストーリー | User Story |
| 受け入れ基準 | Acceptance Criteria |
| 完了の定義 | Definition of Done (DoD) |
| ストーリーポイント | Story Points |
| 依存関係 | Dependencies |
| スコープ | Scope |
| スコープ外 | Out of Scope |
| 分割 | Split / Decompose |
| 不確実性 | Uncertainty |
リファインメントセッションでのフレーズ
| 日本語 | 英語 |
|---|---|
| このチケットの受け入れ基準を明確にしましょう | Let’s clarify the acceptance criteria for this ticket. |
| このストーリーはスプリントに収まりますか？ | Does this story fit within a single sprint? |
| 分割できる部分はありますか？ | Are there parts that can be split off? |
| 依存関係を確認しましょう | Let’s confirm the dependencies. |
| このチケットのスコープを絞りましょう | Let’s narrow the scope of this ticket. |
| 見積もりのポイントをお願いします | Please provide your story point estimate. |
技術的負債の管理は英語テクニカルデット登録の書き方でも確認してほしい。
バックログリファインメントセッションでユーザーストーリーを詳細化する際は英語ユーザーストーリーの書き方の受け入れ基準テンプレートも参考にしてほしい。Given-When-Then形式で書くことでリファインメントの議論が整理しやすくなる。
リファインメントで詳細化したアイテムからスプリントゴールを設定する際は英語スプリントゴールの書き方のゴール文テンプレートも参考にしてほしい。so that 構文でビジネス価値を明示することでゴールの方向性が全員に伝わる。
バックログリファインメントでストーリーを詳細化する際にDoDを参照すると、受け入れ基準の粒度が自然と揃う。英語DoDの書き方で5カテゴリの基準テンプレートも確認してほしい。
リファインメントで見積もったポイントをスプリントに割り当てる際は英語スプリントキャパシティ計画書の書き方のベロシティ比較テーブルも活用してほしい。過去3〜4スプリントの実績と今回のキャパシティを並べることで適切な計画ポイントが決まる。
スパイクの調査結果をバックログリファインメントで共有する際は英語テクニカルスパイクの書き方の「結果報告」テンプレートも参考にしてほしい。疑問への回答と推奨事項をセットで示すことで見積もり更新の根拠が全員に伝わる。
まとめ：英語バックログリファインメントは4つのセクションで完成する
英語バックログリファインメントに必要な構成要素を整理した。
- アイテム詳細化はユーザーストーリー・スコープ・依存関係を明確にし、開発チームが迷わず着手できる状態にする
- 受け入れ基準はテストで検証できる条件として書き、「完了の定義」まで合意する
- 見積もりは根拠と不確実性をセットで記録し、後から計画変更が生じた場合の判断材料にする
- 優先順位はビジネス根拠を明記し、実施スプリントとステークホルダーの承認を記録する
テンプレートをコピーして、まず「ユーザーストーリー」と「受け入れ基準」から書き始めてほしい。この2つが固まれば、見積もりと優先順位の議論が自然と進む。
コメント