agile-product-owner

アジャイルプロダクトオーナー

ユーザーストーリーの生成、受け入れ基準のパターン、スプリント計画、ベロシティ追跡など、プロダクトオーナー向けのバックログ管理およびスプリント実行ツールキットです。

---

目次

• ユーザーストーリー生成ワークフロー
• 受け入れ基準のパターン
• エピック分割ワークフロー
• スプリント計画ワークフロー
• バックログの優先順位付け
• 参考ドキュメント
• ツール

---

最初に明確にすること

ストーリーやスプリント計画を作成する前に、以下の入力を確定します。不明な項目や曖昧な項目が結果を左右する場合は質問し、左右しない場合は妥当な既定値を使用し、使用した値を明示します。

• メリットを得るペルソナ： ストーリーが対象とする具体的なユーザーです（「As a...」の文節と受け入れ基準を決定します）。
• 要件またはエピックの範囲： 機能とその成功条件です（ストーリーの分割と INVEST の検証を決定します）。
• チームのベロシティと稼働状況： 直近の平均ポイント数と、今スプリントの PTO／休日です（確約する作業量と、追加で目指す作業量を決定します）。

リクエストに最も重要な入力を2、3点だけ確認し、リスト全体について尋ねないでください。ユーザーがすぐに結果を求めている場合は、結果を作成し、冒頭に前提条件を記載します。

ユーザーストーリー生成ワークフロー

要件から INVEST に準拠したユーザーストーリーを作成します。

1. ペルソナを特定します（この機能からメリットを得る人）
2. 必要なアクションまたは機能を定義します
3. もたらされるメリットや価値を明確にします
4. Given-When-Then を使って受け入れ基準を作成します
5. フィボナッチ数列を使ってストーリーポイントを見積もります
6. INVEST 基準に照らして検証します
7. 優先順位を付けてバックログに追加します
8. 検証： ストーリーが INVEST 基準をすべて満たし、受け入れ基準がテスト可能であること

ユーザーストーリーのテンプレート

As a [persona],
I want to [action/capability],
So that [benefit/value].

例：

As a marketing manager,
I want to export campaign reports to PDF,
So that I can share results with stakeholders who don't have system access.

ストーリーの種類

種類	テンプレート	例
機能	As a [persona], I want to [action] so that [benefit]	As a user, I want to filter search results so that I find items faster
改善	As a [persona], I need [capability] to [goal]	As a user, I need faster page loads to complete tasks without frustration
バグ修正	As a [persona], I expect [behavior] when [condition]	As a user, I expect my cart to persist when I refresh the page
イネーブラー	As a developer, I need to [technical task] to enable [capability]	As a developer, I need to implement caching to enable instant search

ペルソナの参考例

ペルソナ	典型的なニーズ	コンテキスト
エンドユーザー	効率性、シンプルさ、信頼性	日常的な機能の利用
管理者	制御、可視性、セキュリティ	システム管理
パワーユーザー	自動化、カスタマイズ、ショートカット	熟練者向けワークフロー
新規ユーザー	ガイダンス、学習、安全性	オンボーディング

---

受け入れ基準のパターン

Given-When-Then 形式を使って、テスト可能な受け入れ基準を作成します。

Given-When-Then テンプレート

Given [precondition/context],
When [action/trigger],
Then [expected outcome].

例：

Given the user is logged in with valid credentials,
When they click the "Export" button,
Then a PDF download starts within 2 seconds.

Given the user has entered an invalid email format,
When they submit the registration form,
Then an inline error message displays "Please enter a valid email address."

Given the shopping cart contains items,
When the user refreshes the browser,
Then the cart contents remain unchanged.

受け入れ基準チェックリスト

各ストーリーには、以下のカテゴリの基準を含めます。

カテゴリ	例
正常系	Given valid input, When submitted, Then success message displayed
バリデーション	必須フィールドが空の場合は入力を拒否すること
エラー処理	API が失敗した場合に、ユーザーに分かりやすいメッセージを表示すること
パフォーマンス	操作を2秒以内に完了すること
アクセシビリティ	キーボードのみで操作できること

ストーリーサイズごとの最低基準

ストーリーポイント	最低 AC 数
1-2	3-4 criteria
3-5	4-6 criteria
8	5-8 criteria
13+	ストーリーを分割する

テンプレートの完全なライブラリについては、references/user-story-templates.md を参照してください。

---

エピック分解ワークフロー

エピックを、スプリントで提供できる規模のストーリーに分解します。

1. エピックの範囲と成功基準を定義します
2. エピックの影響を受けるすべてのペルソナを特定します
3. 各ペルソナに必要なすべての機能をリストアップします
4. 機能を論理的なストーリーにグループ化します
5. 各ストーリーが8ポイント以下であることを確認します
6. ストーリー間の依存関係を特定します
7. 段階的に提供できるよう、ストーリーの順序を決めます
8. 検証： 各ストーリーが単独で価値を提供し、すべてのストーリーを合わせてエピックの範囲を網羅していることを確認します

ストーリー分割の判断ロジック

以下のルールを順に適用します。ストーリーに当てはまる最初のルールを使用してください。

#	分割ルール	適用されるケース	分割方法
1	ワークフローのステップ	ストーリーに複数の連続したステップが含まれる	各ステップを独立したストーリーにします
2	ビジネスルールのバリエーション	ストーリーにルールのバリエーション（例：料金プラン、ユーザーロール）が含まれる	各ルールのバリエーションを独立したストーリーにします
3	データのバリエーション	ストーリーが異なるデータ型や形式を扱う	各データ型を独立したストーリーにします
4	複雑な受け入れ条件	ストーリーに、異なる動作を扱う受け入れ条件が8つ以上ある	異なる動作のまとまりごとに独立したストーリーにします
5	大規模な作業	ストーリーに大規模な開発作業（13ポイント以上）が必要	作業のマイルストーンに沿って分割します（基盤 → 機能 → 仕上げ）
6	外部依存関係	ストーリーが外部 API、チーム、または承認に依存する	依存する作業と独立した作業に分けて、別々のストーリーにします
7	DevOps 作業	ストーリーに大規模なインフラ作業が必要	インフラのセットアップと機能の実装に分けます
8	該当なし	ストーリーはすでに小さいものの、内容が明確でない	Tiny Acts of Discovery（TAD）を使用し、不確実性を減らす小規模なスパイクを実施します

分割の出力形式

分割ごとに、次の内容を記録します。

## Original Story
As a [persona], I want to [action] so that [benefit].
Points: 13 | Status: Too large for sprint

## Suggested Splits

### Split 1: By Workflow Steps
- **Story A:** As a [persona], I want to [step 1] so that [partial benefit].
  Points: 5 | Independently valuable: Yes
- **Story B:** As a [persona], I want to [step 2] so that [remaining benefit].
  Points: 5 | Independently valuable: Yes

### Risks & Tradeoffs
- [What coupling exists between the split stories]
- [What is lost by delivering them separately]

### Implementation Order
1. Story A (foundation) → 2. Story B (builds on A)

分割テクニック（クイックリファレンス）

テクニック	使用するケース	例
ワークフローのステップごと	線形のプロセス	「チェックアウト」→「カートに追加」＋「支払い情報を入力」＋「注文を確定」
ペルソナごと	複数のユーザータイプ	「ダッシュボード」→「管理者ダッシュボード」＋「ユーザーダッシュボード」
データ型ごと	複数の入力形式	「インポート」→「CSV をインポート」＋「Excel をインポート」
操作ごと	CRUD 機能	「ユーザーを管理」→「作成」＋「編集」＋「削除」
ビジネスルールごと	ルールのバリエーション	「割引」→「割合割引」＋「定額割引」＋「1 つ買うともう 1 つ無料」
ハッピーパスを最初に	リスクの軽減	「機能」→「基本フロー」＋「エラー処理」＋「エッジケース」
依存関係ごと	外部のブロッカー	「連携」→「モック連携」＋「本番連携」
Tiny Acts of Discovery	不確実性が高い場合	「AI 機能」→「スパイク：実現可能性」＋「MVP の実装」

エピックの例

エピック： ユーザーダッシュボード

内訳：

Epic: User Dashboard (34 points total)
├── US-001: View key metrics (5 pts) - End User
├── US-002: Customize layout (5 pts) - Power User
├── US-003: Export data to CSV (3 pts) - End User
├── US-004: Share with team (5 pts) - End User
├── US-005: Set up alerts (5 pts) - Power User
├── US-006: Filter by date range (3 pts) - End User
├── US-007: Admin overview (5 pts) - Admin
└── US-008: Enable caching (3 pts) - Enabler

---

スプリント計画ワークフロー

スプリントのキャパシティを計画し、ストーリーを選択します。

1. チームのキャパシティを算出します（ベロシティ × 稼働率）
2. ステークホルダーとスプリントゴールを確認します
3. 優先順位を付けたバックログからストーリーを選択します
4. キャパシティの80～85％までをコミット対象として割り当てます
5. ストレッチゴールを追加します（さらに10～15％）
6. 依存関係とリスクを特定します
7. 複雑なストーリーをタスクに分解します
8. 検証： コミットしたポイントがキャパシティの85％以下であり、すべてのストーリーに受け入れ条件があることを確認します

キャパシティの算出

Sprint Capacity = Average Velocity × Availability Factor

Example:
Average Velocity: 30 points
Team availability: 90% (one member partially out)
Adjusted Capacity: 27 points

Committed: 23 points (85% of 27)
Stretch: 4 points (15% of 27)

稼働率の要因

シナリオ	係数
スプリント全期間に参加し、有給休暇なし	1.0
チームメンバー1名が50％不在	0.9
スプリント中に祝日がある	0.8
複数のメンバーが不在	0.7

スプリント割り当てテンプレート

Sprint Capacity: 27 points
Sprint Goal: [Clear, measurable objective]

COMMITTED (23 points):
[H] US-001: User dashboard (5 pts)
[H] US-002: Export feature (3 pts)
[H] US-003: Search filter (5 pts)
[M] US-004: Settings page (5 pts)
[M] US-005: Help tooltips (3 pts)
[L] US-006: Theme options (2 pts)

STRETCH (4 points):
[L] US-007: Sort options (2 pts)
[L] US-008: Print view (2 pts)

計画手順の詳細については、references/sprint-planning-guide.md を参照してください。

---

バックログの優先順位付け

価値と作業量を評価して、バックログの優先順位を付けます。

優先度レベル

優先度	定義	スプリントの目標
クリティカル	ユーザーの作業を妨げる問題、セキュリティ上の問題、データ損失	即時
高	コア機能、ユーザーの重要なニーズ	今回のスプリント
中	改善、機能強化	次の2～3スプリント
低	あれば便利な機能、小規模な改善	バックログ

優先順位付けの要素

要素	重み	質問
ビジネス価値	40%	収益への影響はありますか？ユーザーの需要はありますか？戦略と一致していますか？
ユーザーへの影響	30%	ユーザーは何人いますか？どのくらいの頻度で使用されますか？
リスク／依存関係	15%	技術的なリスクはありますか？外部依存関係はありますか？
工数	15%	規模はどの程度ですか？複雑さはどの程度ですか？不確実性はありますか？

INVEST 基準の検証

スプリントに追加する前に、各ストーリーを検証します。

基準	質問	合格条件
Independent（独立している）	他の未確定ストーリーがなくても開発できますか？	開発を妨げる依存関係がない
Negotiable（交渉可能である）	実装方法に柔軟性がありますか？	複数のアプローチが可能
Valuable（価値がある）	ユーザーまたはビジネスに価値をもたらしますか？	「その結果」の明確なメリットがある
Estimable（見積もり可能である）	チームが見積もりできますか？	規模を見積もれるだけの理解がある
Small（小さい）	1 回のスプリントで完了できますか？	≤8 ストーリーポイント
Testable（テスト可能である）	完了したことを検証できますか？	明確な受け入れ基準がある

---

参考ドキュメント

ユーザーストーリーのテンプレート

references/user-story-templates.md の内容：

• 種類別の標準的なストーリー形式（機能、改善、バグ修正、イネーブラー）
• 受け入れ基準のパターン（Given-When-Then、Should／Must／Can）
• INVEST 基準の検証チェックリスト
• ストーリーポイントの見積もりガイド（フィボナッチ数列）
• よくあるストーリーのアンチパターンと修正方法
• ストーリーの分割手法

スプリント計画ガイド

references/sprint-planning-guide.md の内容：

• スプリント計画ミーティングのアジェンダ
• キャパシティ計算式
• バックログの優先順位付けフレームワーク（WSJF）
• スプリントセレモニーのガイド（スタンドアップ、レビュー、振り返り）
• ベロシティの追跡とバーンダウンのパターン
• 完了の定義チェックリスト
• スプリントの指標と目標

---

ツール

ユーザーストーリー生成ツール

# Generate stories from sample epic
python scripts/user_story_generator.py

# Plan sprint with capacity
python scripts/user_story_generator.py sprint 30

以下を生成します：

• INVEST に準拠したユーザーストーリー
• Given-When-Then 形式の受け入れ基準
• ストーリーポイントの見積もり（フィボナッチ数列）
• 優先順位の割り当て
• コミット済みアイテムとストレッチアイテムを含むスプリントへの割り当て

出力例

USER STORY: USR-001
========================================
Title: View Key Metrics
Type: story
Priority: HIGH
Points: 5

Story:
As a End User, I want to view key metrics and KPIs
so that I can save time and work more efficiently

Acceptance Criteria:
  1. Given user has access, When they view key metrics, Then the result is displayed
  2. Should validate input before processing
  3. Must show clear error message when action fails
  4. Should complete within 2 seconds
  5. Must be accessible via keyboard navigation

INVEST Checklist:
  ✓ Independent
  ✓ Negotiable
  ✓ Valuable
  ✓ Estimable
  ✓ Small
  ✓ Testable

---

スプリントの指標

スプリントの健全性とチームのパフォーマンスを追跡します。

主な指標

指標	計算式	目標
ベロシティ	完了したポイント数 / スプリント	±10% 以内で安定
コミットメントの信頼性	完了数 / コミット数	>85%
スコープ変更	スプリント途中で追加または削除されたポイント数	<10%
持ち越し	未完了のポイント数	<15%

ベロシティの追跡

Sprint 1: 25 points
Sprint 2: 28 points
Sprint 3: 30 points
Sprint 4: 32 points
Sprint 5: 29 points
------------------------
Average Velocity: 28.8 points
Trend: Stable

Planning: Commit to 24-26 points

完了の定義

ストーリーは次の条件を満たすと完了です：

• コードが完成し、ピアレビュー済みである
• 単体テストが作成され、合格している
• 受け入れ基準が検証済みである
• ドキュメントが更新されている
• ステージング環境にデプロイされている
• プロダクトオーナーが承認している
• 重大なバグが残っていない

---

ツールのリファレンス

user_story_generator.py

サンプルのエピックから、受け入れ基準、ストーリーポイントの見積もり、優先順位の割り当て、スプリント計画を含む、INVEST に準拠したユーザーストーリーを生成します。

引数	型	デフォルト	説明
sprint	サブコマンド	-	スプリント計画モードで実行します
[capacity]	int	30	ストーリーポイントで表したスプリントのキャパシティ（sprint と併用）

# Generate stories from sample epic
python scripts/user_story_generator.py

# Sprint planning with capacity
python scripts/user_story_generator.py sprint 30
python scripts/user_story_generator.py sprint 45

出力内容：

• ストーリー ID、タイトル、種類、優先順位、ポイント見積もり
• 「As a... I want... So that...」形式のユーザーストーリーの説明
• ストーリーごとに 5 つの受け入れ基準（Given-When-Then、検証、エラー、パフォーマンス、アクセシビリティ）
• ストーリーごとの INVEST 基準チェックリスト
• 優先順位の内訳を含むバックログの概要
• コミット済みアイテムとストレッチアイテムを含むスプリントへの割り当て（スプリントモードの場合）

---

トラブルシューティング

問題	原因	解決策
ストーリーが大きすぎる（>8 ポイント）	エピックの分割が不十分	ワークフローのステップ、ペルソナ、または CRUD 操作ごとに分割する手法を適用します
受け入れ条件がテストできない	条件に曖昧な表現が使われている	具体的で観察可能な結果を含む Given-When-Then 形式で書き直します
スプリントのコミットメントを繰り返し達成できない	ベロシティが安定していない、または目標が高すぎる	3 回以上のスプリントでベロシティを追跡し、直近の平均の 80～85% をコミットします
持ち越しストーリーが多すぎる	スプリント途中でのスコープ変更、または見積もりの不備	スコープ変更禁止のルールを徹底し、プランニングポーカーを使って見積もりを調整します
ストーリーの価値が明確でない	「その結果」の便益を示す節がない	すべてのストーリーについて、誰が恩恵を受けるのか、何を得られるのか、なぜ重要なのかを答えているか確認します
スプリントの依存関係が多すぎる	ストーリーが独立していない	バックログの順序を見直し、依存するストーリーを独立したスライスに分割します
ステークホルダー間で優先順位について意見が分かれる	客観的な優先順位付けのフレームワークがない	WSJF または価値／工数スコアリングを使い、判断の根拠を記録します

---

成功基準

基準	目標	測定方法
コミットメントの信頼性	コミットしたポイントの >85% を完了	スプリントごとの完了ポイント数 / コミットしたポイント数
INVEST 準拠	すべてのストーリーが 6 つの基準をすべて満たす（100%）	user_story_generator の INVEST チェックリスト
ベロシティの安定性	直近の平均の +/-10% 以内	5 回以上のスプリントでベロシティの推移を追跡
スコープ変更	スプリントのポイントの <10% がスプリント途中で追加または削除される	計画後に追加または削除されたポイント数を数える
持ち越し率	コミットしたポイントの <15%	未完了ポイント数 / コミットしたポイント数
受け入れ条件の品質	すべての条件がテスト可能で、検証済み	スプリント開始前に受け入れ条件について QA の承認を得る
バックログの精査	バックログの直近 2 スプリント分が常に準備済み	受け入れ条件を含む、精査済みストーリーの数

---

スコープと制限事項

対象範囲:

• INVEST 検証を含むユーザーストーリーの生成
• Given-When-Then 形式での受け入れ条件
• キャパシティに基づく負荷設定を用いたスプリント計画
• エピックをスプリント規模のストーリーに分割
• バックログの優先順位付けフレームワーク（WSJF、価値／工数）
• ベロシティの追跡とスプリント指標
• 完了の定義の徹底

対象外:

• Jira/Linear のチケット作成（各サービスの API で JSON をエクスポートします）
• バーンダウンチャートの可視化（プロジェクト管理ツールのダッシュボードを使用します）
• チームメンバーの割り当てと、個人ごとのキャパシティ
• チーム間の依存関係管理（プログラムレベルのツールを使用します）
• 四半期の範囲を超えるリリース計画
• 受け入れテストの自動生成（エンジニアリングスキルを参照してください）

---

統合ポイント

ツール／プラットフォーム	統合方法	ユースケース
Jira / Linear	ストーリーの出力をコピーするか、スクリプトを拡張して JSON をエクスポート	生成したストーリーをチケットとしてインポート
Confluence / Notion	人が読みやすい形式の出力を貼り付ける	スプリント計画とバックログを記録
Slack	スプリント計画の概要を共有	非同期でスプリント開始時のコミュニケーションを行う
product-manager-toolkit	RICE スコアをストーリーの優先順位付けに反映	スプリントの優先順位をプロダクト戦略に合わせる
product-strategist	OKR のカスケードをエピック選定に反映	スプリントの作業を四半期の目標につなげる
ux-researcher-designer	ペルソナデータをストーリーのペルソナに反映	調査に基づくペルソナをユーザーストーリーの基盤にする