アジャイルプロダクトオーナー は何をしますか？
プロダクトオーナー向けのバックログ管理およびスプリント実行ツールキット。ユーザーストーリー生成、受け入れ基準パターン、スプリント計画、ベロシティ追跡を含みます。
目次
ユーザーストーリー生成ワークフロー
要件からINVEST準拠のユーザーストーリーを作成します。
- ペルソナを特定する（この機能から誰が利益を得るか）
- 必要なアクションまたは機能を定義する
- 提供されるメリットまたは価値を明確にする
- Given-When-Thenを使用して受け入れ基準を記述する
- フィボナッチスケールを使用してストーリーポイントを見積もる
- INVEST基準に対して検証する
- 優先順位を付けてバックログに追加する
- 検証: ストーリーはすべてのINVEST基準を満たし、受け入れ基準はテスト可能である
ユーザーストーリーテンプレート
[ペルソナ]として、
[アクション/機能]を実行したい、
それによって[メリット/価値]が得られる。
例:
マーケティングマネージャーとして、
キャンペーンレポートをPDFにエクスポートしたい、
それによってシステムにアクセスできないステークホルダーと結果を共有できる。
ストーリータイプ
| タイプ | テンプレート | 例 |
|---|---|---|
| 機能 | [ペルソナ]として、[アクション]を実行して[メリット]を得たい | ユーザーとして、検索結果をフィルタリングしてアイテムをより早く見つけたい |
| 改善 | [ペルソナ]として、[目標]のために[機能]が必要 | ユーザーとして、フラストレーションなくタスクを完了するためにページの読み込みを高速化する必要がある |
| バグ修正 | [ペルソナ]として、[条件]の場合に[動作]を期待する | ユーザーとして、ページを更新したときにカートが保持されることを期待する |
| イネーブラー | 開発者として、[機能]を有効にするために[技術的タスク]が必要 | 開発者として、インスタント検索を有効にするためにキャッシュを実装する必要がある |
ペルソナリファレンス
| ペルソナ | 典型的なニーズ | コンテキスト |
|---|---|---|
| エンドユーザー | 効率性、シンプルさ、信頼性 | 日常的な機能使用 |
| 管理者 | 制御、可視性、セキュリティ | システム管理 |
| パワーユーザー | 自動化、カスタマイズ、ショートカット | エキスパートワークフロー |
| 新規ユーザー | ガイダンス、学習、安全性 | オンボーディング |
受け入れ基準パターン
Given-When-Then形式を使用してテスト可能な受け入れ基準を記述します。
Given-When-Thenテンプレート
前提[前提条件/コンテキスト]、
条件[アクション/トリガー]、
結果[期待される結果]。
例:
ユーザーが有効な認証情報でログインしている前提で、
「エクスポート」ボタンをクリックすると、
2秒以内にPDFダウンロードが開始される。
ユーザーが無効なメール形式を入力した前提で、
登録フォームを送信すると、
「有効なメールアドレスを入力してください」というインラインエラーメッセージが表示される。
ショッピングカートにアイテムが含まれている前提で、
ブラウザを更新すると、
カートの内容は変更されずに保持される。
受け入れ基準チェックリスト
各ストーリーには以下のカテゴリの基準を含める必要があります。
| カテゴリ | 例 |
|---|---|
| ハッピーパス | 有効な入力が与えられた前提で、送信されると、成功メッセージが表示される |
| バリデーション | 必須フィールドが空の場合、入力を拒否する必要がある |
| エラーハンドリング | APIが失敗した場合、ユーザーフレンドリーなメッセージを表示する必要がある |
| パフォーマンス | 操作を2秒以内に完了する必要がある |
| アクセシビリティ | キーボードのみでナビゲート可能である必要がある |
ストーリーサイズ別の最小基準数
| ストーリーポイント | 最小AC数 |
|---|---|
| 1-2 | 3-4基準 |
| 3-5 | 4-6基準 |
| 8 | 5-8基準 |
| 13+ | ストーリーを分割 |
完全なテンプレートライブラリについては、references/user-story-templates.md を参照してください。
エピック分割ワークフロー
エピックをスプリント単位のストーリーに分割します。
- エピックの範囲と成功基準を定義する
- エピックの影響を受けるすべてのペルソナを特定する
- 各ペルソナに必要なすべての機能をリストアップする
- 機能を論理的なストーリーにグループ化する
- 各ストーリーが8ポイント以下であることを検証する
- ストーリー間の依存関係を特定する
- 段階的なデリバリーのためにストーリーを順序付ける
- 検証: 各ストーリーがスタンドアロンの価値を提供し、すべてのストーリーがエピックの範囲をカバーしている
分割テクニック
| テクニック | 使用タイミング | 例 |
|---|---|---|
| ワークフローステップごと | 線形プロセス | 「チェックアウト」→「カートに追加」+「支払い入力」+「注文確認」 |
| ペルソナごと | 複数のユーザータイプ | 「ダッシュボード」→「管理者ダッシュボード」+「ユーザーダッシュボード」 |
| データタイプごと | 複数の入力 | 「インポート」→「CSVインポート」+「Excelインポート」 |
| 操作ごと | CRUD機能 | 「ユーザー管理」→「作成」+「編集」+「削除」 |
| ハッピーパス優先 | リスク低減 | 「機能」→「基本フロー」+「エラーハンドリング」+「エッジケース」 |
エピック例
エピック: ユーザーダッシュボード
分割:
エピック: ユーザーダッシュボード (合計34ポイント)
├── US-001: 主要指標を表示 (5pts) - エンドユーザー
├── US-002: レイアウトをカスタマイズ (5pts) - パワーユーザー
├── US-003: データをCSVにエクスポート (3pts) - エンドユーザー
├── US-004: チームと共有 (5pts) - エンドユーザー
├── US-005: アラートを設定 (5pts) - パワーユーザー
├── US-006: 日付範囲でフィルタリング (3pts) - エンドユーザー
├── US-007: 管理者概要 (5pts) - 管理者
└── US-008: キャッシュを有効にする (3pts) - イネーブラー
スプリント計画ワークフロー
スプリント容量を計画し、ストーリーを選択します。
- チーム容量を計算する（ベロシティ × 可用性）
- スプリント目標をステークホルダーとレビューする
- 優先順位付けされたバックログからストーリーを選択する
- 容量の80-85%（確約）まで埋める
- ストレッチゴールを追加する（さらに10-15%）
- 依存関係とリスクを特定する
- 複雑なストーリーをタスクに分割する
- 検証: 確約ポイント ≤85%容量、すべてのストーリーに受け入れ基準がある
容量計算
スプリント容量 = 平均ベロシティ × 可用性係数
例:
平均ベロシティ: 30ポイント
チーム可用性: 90%（メンバー1名が部分的に欠勤）
調整後容量: 27ポイント
確約: 23ポイント (27の85%)
ストレッチ: 4ポイント (27の15%)
可用性係数
| シナリオ | 係数 |
|---|---|
| フルスプリント、有給休暇なし | 1.0 |
| チームメンバー1名が50%欠勤 | 0.9 |
| スプリント中の祝日 | 0.8 |
| 複数メンバー欠勤 | 0.7 |
スプリントローディングテンプレート
スプリント容量: 27ポイント
スプリント目標: [明確で測定可能な目的]
確約 (23ポイント):
[H] US-001: ユーザーダッシュボード (5pts)
[H] US-002: エクスポート機能 (3pts)
[H] US-003: 検索フィルター (5pts)
[M] US-004: 設定ページ (5pts)
[M] US-005: ヘルプツールチップ (3pts)
[L] US-006: テーマオプション (2pts)
ストレッチ (4ポイント):
[L] US-007: ソートオプション (2pts)
[L] US-008: 印刷ビュー (2pts)
完全な計画手順については、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)
- スプリントセレモニーガイド（デイリースクラム、レビュー、レトロスペクティブ）
- ベロシティ追跡とバーンダウンパターン
- 完了の定義チェックリスト
- スプリントメトリクスと目標
ツール
ユーザーストーリー生成ツール
# サンプルエピックからストーリーを生成
python scripts/user_story_generator.py
# 容量を指定してスプリントを計画
python scripts/user_story_generator.py sprint 30
生成されるもの:
- INVEST準拠のユーザーストーリー
- Given-When-Then受け入れ基準
- ストーリーポイント見積もり（フィボナッチスケール）
- 優先順位割り当て
- 確約アイテムとストレッチアイテムを含むスプリントローディング
サンプル出力
ユーザーストーリー: USR-001
========================================
タイトル: 主要指標の表示
タイプ: ストーリー
優先度: 高
ポイント: 5
ストーリー:
エンドユーザーとして、主要指標とKPIを表示したい
それによって時間を節約し、より効率的に作業できる
受け入れ基準:
1. ユーザーがアクセス権を持っている前提で、主要指標を表示すると、結果が表示される
2. 処理前にバリデートする必要がある
3. アクションが失敗した場合、明確なエラーメッセージを表示する必要がある
4. 2秒以内に完了する必要がある
5. キーボードナビゲーションでアクセス可能である必要がある
INVESTチェックリスト:
✓ 独立
✓ 交渉可能
✓ 価値がある
✓ 見積もり可能
✓ 小さい
✓ テスト可能
スプリントメトリクス
スプリントの健全性とチームのパフォーマンスを追跡します。
主要メトリクス
| メトリクス | 式 | 目標 |
|---|---|---|
| ベロシティ | 完了ポイント / スプリント | 安定 ±10% |
| 確約信頼性 | 完了 / 確約 | >85% |
| スコープ変更 | スプリント中に追加または削除されたポイント | <10% |
| 持越し | 未完了ポイント | <15% |
ベロシティトラッキング
スプリント1: 25ポイント
スプリント2: 28ポイント
スプリント3: 30ポイント
スプリント4: 32ポイント
スプリント5: 29ポイント
------------------------
平均ベロシティ: 28.8ポイント
傾向: 安定
計画: 24〜26ポイントを確約
完了の定義
ストーリーが完了したとみなされる条件:
- コードが完了し、ピアレビューが行われている
- 単体テストが作成され、成功している
- 受け入れ基準が検証されている
- ドキュメントが更新されている
- ステージング環境にデプロイされている
- プロダクトオーナーが受け入れている
- クリティカルなバグが残っていない
関連スキル
- スクラムマスター (
project-management/scrum-master/) — ベロシティデータとスプリントセレモニーがバックログ管理を補完します - プロダクトマネージャーツールキット (
product-team/product-manager-toolkit/) — RICE優先順位付けがバックログの順序付けに貢献します