agile-product-owner

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

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

---

目次

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

---

このスキルの特長

• **現実に即したキャパシティ計算：**スプリントのキャパシティは希望的観測ではなく、ベロシティ × 稼働率係数に基づきます。
• **ストーリーの規模に応じた受け入れ条件：**大きな項目の仕様不足を防ぐため、ストーリーポイントに応じた受け入れ条件の最小数を設定します。
• **一貫性を保つ重み付けによる優先順位付け：**価値 40％、影響 30％、リスク 15％、工数 15％とし、トレードオフを明確にします。
• **体系的なエピック分割手法：**具体的な 5 つの分割パターンで、ストーリーが大きくなりすぎるのを防ぎます。
• **INVEST による検証をワークフローに組み込み：**各ストーリーには、指針だけでなく検証ステップも含まれます。

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

要件から 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 [ペルソナ], I want to [アクション] so that [メリット]	As a user, I want to filter search results so that I find items faster
改善	As a [ペルソナ], I need [機能] to [目標]	As a user, I need faster page loads to complete tasks without frustration
バグ修正	As a [ペルソナ], I expect [動作] when [条件]	As a user, I expect my cart to persist when I refresh the page
イネーブラー	As a developer, I need to [技術的なタスク] to enable [機能]	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 秒以内に処理を完了する必要があります
アクセシビリティ	キーボード操作のみで操作できる必要があります

ストーリー規模ごとの受け入れ条件の最小数

ストーリーポイント	受け入れ条件の最小数
1-2	3-4 件
3-5	4-6 件
8	5-8 件
13+	ストーリーを分割します

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

---

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

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

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

分割テクニック

テクニック	使用する状況	例
ワークフローのステップ別	直線的なプロセス	「チェックアウト」→「カートに追加」＋「支払い情報を入力」＋「注文を確定」
ペルソナ別	複数のユーザータイプ	「ダッシュボード」→「管理者ダッシュボード」＋「ユーザーダッシュボード」
データタイプ別	複数の入力形式	「インポート」→「CSVをインポート」＋「Excelをインポート」
操作別	CRUD 機能	「ユーザーを管理」→「作成」＋「編集」＋「削除」
ハッピーパスを優先	リスク低減	「機能」→「基本フロー」＋「エラー処理」＋「エッジケース」

エピックの例

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

分解：

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

完了の定義

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

• コードが完成し、ピアレビュー済み
• ユニットテストが作成され、すべて成功
• 受け入れ条件を検証済み
• ドキュメントを更新済み
• ステージング環境にデプロイ済み
• プロダクトオーナーが承認済み
• 重大なバグが残っていない