スクラムにおける良いユーザーストーリーの書き方

技術プロジェクトの約70％が失敗する。数十年にわたり、プロジェクトが失敗するのは、ベストプラクティスに従っていないか、必要なスキルがチームに不足しているためだと広く信じられてきた。しかし、ベストプラクティスやスキル、能力の導入は数十年にわたり改善されてきた。それにもかかわらず、なぜプロジェクトは依然として失敗するのだろうか？

ソフトウェアプロジェクトの70％が要件の不備によって失敗していることを考慮すると、これらの失敗に伴う再作業の推定額は年間450億ドルを超える。

問題は――なぜこのようなことが起こるのか？その答えは二つある。第一に、ビジネス要件はしばしば顧客への焦点を失ってしまう。第二に、要件には、要件アナリストが顧客のニーズや戦略から実装されるソリューションに至るまで、要件を追跡・駆動できる包括的な参照枠組みが欠けている。

良い要件やユーザーストーリーを書くには、以下の手順に従ってください：

1. システムの利用者を表すために、可能な限り多くのペルソナを定義してください。これにより、顧客に焦点を当て、顧客のニーズに基づいて要件を駆動し追跡できるようになります。アラン・クーパーによって提唱されたペルソナは、システムの典型的な利用者を定義するものであり、システムとやり取りする人々の例です。利用者は個人である必要はなく、個人を表す必要もありません。利用者として組織を表すことも可能です。
2. ユーザーストーリーが「3C」に従っていることを確認してください：

• カード — インデックスカードまたはステッカーに書くべき
• 会話 — プロダクトオーナーから詳細情報を得る
• 確認 — 正しく実装されていることを確認する。ユーザー受入基準を満たしている必要がある。

3. ユーザーストーリーを分割し、スプリントに適切なサイズになるようにする。ストーリーを分割する方法には以下のようなものがある：

• ワークフローのステップごとに分割
• 入力／出力チャネルごとに分割
• ユーザーの選択肢ごとに分割
• ペルソナ／役割ごとに分割
• データ範囲ごとに分割

4. すべてのユーザーストーリーがINVESTの暗記法に従うようにする：

アジャイルなINVESTの暗記法ビル・ウェイクによって作成されたもので、通常ユーザーストーリー形式で書かれる高品質なプロダクトバックログアイテム（PBI）を確保するためのガイドラインとして機能する。

• 独立性：ストーリーはできるだけ独立しているべきである。
• 交渉可能：ストーリーは契約ではない。ストーリーは会話への招待である。ストーリーは望まれるものの本質を捉えている。
• 価値ある: ストーリーに明確な価値がない場合は、実施すべきでない。
• 見積もり可能: ストーリーは見積もり可能またはサイズが明確でなければならない。そうすることで適切に優先順位をつけることができる。
• 小さく: 2週間のイテレーションでは、ユーザー ストーリーの平均作業量は3～4日間（合計）が目安です！これは、ストーリーを「完了」状態にまで持っていくために必要なすべての作業を含む。ユーザー ストーリーが小さければ小さいほど、見積もりの正確性は高くなる！
• 検証可能: すべてのストーリーは、「完了」と見なされるためには検証可能でなければならない。

• ユーザー ストーリーに向けたSMART目標とINVESTの書き方
• テーマ vs エピック vs ユーザー ストーリー vs タスク
• プロダクトバックログにおけるDEEPとは何か？
• スクラムプロジェクトのためのプロダクトビジョンの書き方
• アジャイル開発にスクラムボードを使う方法
• スクラムにおいて、プロダクトバックログ項目やユーザー ストーリーは誰が作成するのか？
• アジャイル見積もりとは何か？
• アジャイルにおけるストーリーポイントとは何か？ユーザー ストーリーの見積もりの仕方
• ユーザー ストーリーの分割 – 垂直スライス vs 水平スライス