ユーザー ストーリーは、エクストリーム プログラミングから生まれたツールであり、アジャイル チームが要求を文書化して収集するための事実上の手段となっています。
ご存じない方もいらっしゃるかもしれませんが、ストーリーとは、ビジネスのニーズを把握し、作業を計画することができる軽量の成果物です。 ストーリーは通常、ビジネスや顧客の言語でインデックスカード(3×5や4×6の小さなカード)に書かれます。 ユーザーストーリーでは、ユーザーのニーズを把握するのに必要なことだけを書き、それ以上は書かないようにします。
適切に使用すれば、ユーザー ストーリーの詳細のなさは、私たちに非常に大きな実用性をもたらします。 要件についての話が終わったら、リスクを検討したり、依存関係を特定したり、プロジェクトプランを作成したりと、インデックスカードを手放すことなく作業を進めることができます。 すごいですね。
長年にわたり、ストーリーで本当に成功している人々は、すべてのストーリーに見られるいくつかの共通点に落ち着いています。
- 役割: 誰が、または何が、この機能を使用するのか
- 機能 (またはケイパビリティ): チームが作業を終えた後、何を提供または追加しようとしているのか
- 価値: ビジネスがなぜこの機能を必要としているのか。
- 受け入れ基準: この機能が完了したかどうかをどのように確認するか
- 見積もり: チームはこの機能にどのくらいのコストがかかると考えているか
IMOでは、ストーリーが完成したとみなされるためには、上記のすべての特性を持っていなければなりません。 すべての特性を定義するのが難しい場合、そのストーリーは私が言うところの「熟していない」、つまり、チームで使用できるほどよく考えられていないことがわかります。
Mike Cohn 氏は、ユーザー ストーリーに関する素晴らしい本を書きました。
Mike Cohn氏はユーザー ストーリーに関する素晴らしい本を書きましたが、残念なことに、この本の中で人々が注目しているのは、ユーザー ストーリー テンプレートという1つのガラクタのようです。 本の中でマイクは、いくつかのチームがストーリーを書くのに役立ったというテンプレートを紹介していますが、このテンプレートがあまりにも多くの悪いストーリーの原因となっているため、私はこれ以上このテンプレートにインク（またはビット）を与えるつもりはありません。 私がこのテンプレートに異議を唱えるのは、役割、機能、価値を機械的に記入し、受け入れ基準や見積もりを省略することで、人々の思考を停止させてしまうからです（おそらくテンプレートにはそれらが欠けているからでしょう）。
ストーリーで苦労している人を見ると、5、6 年前に無名のチーム (おそらくこのテンプレートをもう使用していない) に役立ったテンプレートに、自分たちのビジネスを押し込めようとしているため、驚くべきことに、現在の状況に合っていないのです。
ストーリーを書く前に必要な思考プロセスがありますが、ストーリーを書くことに成功している人のステップは以下の通りです。 私の記事ではこれらのステップが直線的になっていますが、意味があるようにジャンプしたり、前進したり、スキップしたりすることができることを覚えておいてください。
- あなたのシステムを使用する役割 (またはユーザー) は何ですか
- 彼らのニーズは何ですか
- これらの役割にどのような機能 (または性能) を提供したいですか?
- これらの機能はなぜビジネスにとって価値があるのですか? これらの機能からどのような種類のビジネス成果が期待できるか？
- これらの機能の優先順位は何か？
- これらの機能が完了したかどうかをどのようにして知ることができるか
?
最後に、ストーリーカードの前面にたくさんの詳細を書きたがる傾向があります。 このような人には2つの提案があります。 まず、もっと小さなカードを使いましょう。 ユーザーストーリーは仕様書や要求書ではありません。 ユーザーストーリーは、ユーザーのニーズを記録したインデックスカードであり、実装の詳細を後で記録しなければならないことを思い出させてくれるものです。 もしインデックスカードにどんどん詰め込もうとしているのであれば、それはユーザーストーリーに加えて仕様書や何らかの設計書が必要であるというサインかもしれません。 第二に、人々が書き留めようとしている詳細のタイプは、実際には受け入れ基準です。 それらの詳細をテスト ケースに押し込むことで、ストーリーをビジネスの言語で維持し、チームが提供する機能や価値に焦点を当て続けることができます。