user-story-writing

ユーザーストーリーの作成

目次

• 概要
• 使用する場面
• クイックスタート
• リファレンスガイド
• ベストプラクティス

概要

適切に作成されたユーザーストーリーは、ユーザー中心の方法で要件を伝え、議論を促進し、開発者やテスターに明確な受け入れ基準を示します。

使用する場面

• 要件を開発タスクに分割する
• プロダクトバックログを作成し、リファインメントする
• アジャイルスプリントを計画する
• 開発チームに機能を伝える
• 受け入れ基準を定義する
• テストケースを作成する

クイックスタート

最小限の実用例：

# User Story Template

**Title:** [Feature name]

**As a** [user role/persona]
**I want to** [action/capability]
**So that** [business value/benefit]

---

## User Context

- User Role: [Who is performing this action?]
- User Goals: [What are they trying to accomplish?]
- Use Case: [When do they perform this action?]

---

## Acceptance Criteria

Given [precondition]
When [action]
Then [expected result]

Example:
// ... (see reference guides for full implementation)

リファレンスガイド

references/ ディレクトリにある詳細な実装：

ガイド	内容
ストーリーのリファインメントプロセス	ストーリーのリファインメントプロセス
受け入れ基準の例	受け入れ基準の例
ストーリーの分割	ストーリーの分割
ストーリーの見積もり	ストーリーの見積もり

ベストプラクティス

✅ 推奨事項

• ユーザーの視点で書く
• 実装ではなく価値に焦点を当てる
• 1スプリントで完了できるサイズのストーリーを作成する
• 明確な受け入れ基準を定義する
• 一貫した形式と用語を使用する
• プロダクトオーナーにストーリーを承認してもらう
• エッジケースやエラーシナリオを含める
• 要件やビジネス目標へのリンクを追加する
• 学びに応じてストーリーを更新する
• テスト可能なストーリーを作成する

❌ 非推奨事項

• 技術的なタスクに偏ったストーリーを書く
• 過度に詳細な仕様を作成する
• 複数のスプリントが必要なストーリーを書く
• 非機能要件を忘れる
• 受け入れ基準を省略する
• 不必要に依存関係のあるストーリーを作成する
• 曖昧な受け入れ基準を書く
• エッジケースを無視する
• 大きすぎるストーリーを作成する
• 議論せずにスプリント中にストーリーを変更する