ユーザー ストーリーとは何か、そうでないもの
エクストリーム プログラミング (XP)、Kanban、Scrum の結果、ユーザー ストーリーは、プロジェクトをスプリントとイテレーションのためのより小さな増分セグメントに分割する必要がある結果として生み出されました。これらは、可能な限り小さな作業単位に焦点を当てるという点で、ユース ケースとは異なります。当初イヴァル・ジェイコブソンが紹介したユース ケースは、共通のテーマに基づいていくつかのストーリーで構成される場合があります。ストーリー自体は、単一の期待またはユーザー目標を概説するシンプルな物語です。ユーザー ストーリーの作成は、次の 3 つの段階に分けることができます。
- 必要性を説明します。
- イテレーションを計画します。
- ストーリーの完了を実装し、テストします。
各段階で、ユーザー ストーリーを完璧に洗練できます。
ユーザー ストーリーには要件リストやコーディング手順は含まれませんが、受け入れ基準やテストに関連付けられます。しかし、ユーザー ストーリーの目標は、構築方法に焦点を当てることではありません。その代わりに、誰が機能を求め、何をするのか、なぜそれが重要なのかに焦点を当てます。ストーリーは、最終的にバックログ アクティビティの To-Do リストを構成する機能に人間の要素をもたらします。
ユーザー ストーリーはなぜ重要なのですか?
ストーリーは単なる機能のリストだけでなく、ユーザーを会話に取り込みます。ユーザー ストーリーは、ユーザーが経験する価値に焦点を当てることで、ソフトウェア開発の背景情報を提供します。この人が最初に行うプロセスはアジャイルの言語をミュートし、開発者以外の人が共同作業を行い、会話に参加できるようにします。
ユーザー ストーリーは、IT 開発プロジェクト全体を通じて絶え間ないダイアログを促進し、イテレーション/スプリントの計画 やリリースのバックログの優先順位付けなどの分野を支援するのに役立ちます。対照的に、従来の Waterfall 開発では、開発プロセスの最初と最後にダイアログが採用されています。
『アジャイル ソフトウェアに適用されたユーザー ストーリー』の中で、マウンテン・ゴート・ソフトウェアのマイク・コーン氏は、「私たちは目の前の情報に基づいて意思決定を行い、頻繁に行います。プロジェクトの最初に包括的な一連の意思決定を行うのではなく、プロジェクト期間中に意思決定を広めます。そのためには、できるだけ早く、頻繁に情報を得るプロセスが用意されていることを確認します。そして、これがユーザー ストーリーの入り込み場所です」と述べました。
ユーザー ストーリーを書く人は誰ですか?
製品所有者、関係者、製品マネージャー、その他のビジネス チーム メンバーが、ユーザー ストーリーの作成に参加します。しかし、誰が書くのかは、ストーリーを生き生きとさせる議論や会話に参加する人よりも重要ではない、と多くの人が言うでしょう。まず、必要に応じて詳細な機能 (ペルソナ) を使用する人を特定します。ユーザーは、学生、フリークエント・フライヤー、マーケティング・マネージャーなど、機能やジョブ ディスクリプションの面で定義できます。
エンド ユーザーを強く理解すると、開発者の偏見や仮定が制限されます。ユーザーが利用できる場合は参加できますが、多くの場合、チームには顧客プロキシとして機能するデザイナー、マネージャー、ライターなどがいます。参加者は、ユーザー ストーリーの使用状況によって異なる場合があります。例:
- ユーザー ストーリー作成: 参加者には、顧客、製品管理、エンジニアリング、人事、財務、セールスなどのその他の関係者が含まれます。
- ユーザー ストーリー メンテナンス: 参加者には製品管理または製品所有者が含まれます。
- ユーザー ストーリーのアプリケーションと使用法: 参加者には、エンジニア/開発者、テクニカル ライター、品質保証テスターが含まれます。
効果的なユーザー ストーリーの作成方法
ユーザー ストーリーは、貴重な機能を備えたシンプルでワンラインの福利厚生ステートメントです。ユーザー ストーリーを作成する前に、ユーザー アンケートとインタビューを行い、必要な機能についてユーザーに問い合わせてください。まず、3x5 インチのカードまたはポスト it ノートに、インクリメンタル ストーリーで記載されたカスタマー ジャーニーを作成することから始めます。これらのカードは、すぐに本番環境に投入することも、バックログのコンテキストを提供することもできます。
ユーザー ストーリー マッピングの場合は、会議室の壁にポスト it ノートを表示して、チーム全体がそれを確認し、長距離計画に取り組むことができます。
必要なストーリーを書くために使用できるテクニックがいくつかあります。一般的なテクニックは、この文の空白を入力して構築する役割特徴理由または利益 (RGB) 構造です。
- (ユーザー/ペルソナ/顧客) として、私が利益を得られるように (何かを) したいと思います。
RGB の質問に加えることは、ロン・ジェフリーズが開発した手法で、彼の「3 つの C アプローチ:」を強調するものです。
- カード: カードに RGB (上記) に対する答えを書きます。
- 会話: カードの限られた詳細は、2 番目の C によって達成された約束の基礎です。このフェーズでは、チームは詳細について話し合い、「完了」の定義を確立します。
- 確認: これは、テストまたは受け入れ基準を決定するフィードバックの結果です。この受け入れ基準は、多くの場合、カードの裏面に書き込まれており、今後の会議で完了を決定するための最初のチェックリストとして使用されます。
2003 年に Bill Wake の記事で初めて紹介され、Mike Cohn 氏の著書『アジャイル ソフトウェア開発に適用されたユーザー ストーリー』で人気を集めた頭文字 INVEST は、ユーザー ストーリーを評価する方法です。投資基準は次のとおりです。
- 任意の順序で開発する独立性。
- ストーリーの展開範囲を交渉する能力。
- ユーザーまたはビジネスに価値を提供する。
- 完了を見積もることができる。
- 1 回のイテレーションで設計、コード化、テストできるほど小さい。
- そして最後に、テストすることができる。
RGB と 3 つの Cs 手法に従ったユーザー ストーリーの作成は、出発点として良いでしょう。INVEST ゴールに対する効果を評価することで、ストーリーは小さく、機能的で、テスト可能になります。
アジャイル ユーザー ストーリー テンプレート
ユーザー ストーリーを作成する準備はできましたか? 無料のテンプレートをダウンロードして、エンド ユーザーの視点から機能を明確に定義できます。テンプレートには、ユーザーの種類、必要なもの、必要な理由などのスペースが含まれています。これらの短い 1 文のユーザー ストーリーを作成することで、開発チームはユーザー ストーリーの要件を満たすコードを開発できます。ダウンロードできるその他の便利なアジャイル テンプレートはこちらでご覧ください。
アジャイル ユーザー ストーリー テンプレートをダウンロード
ユーザー ストーリーからテスト ケースを作成する方法
ユーザー ストーリーは、テストや受け入れ基準を作成するためのガイダンスを提供します。このチェックリストは、開発者が機能の完了時期を判断するのに役立ちます。ユーザー ストーリーのすべての要素と同様に、受け入れ基準もユーザーの観点から書かれています。テストまたは受け入れ基準は、必要な機能を正常に実行するために必要な要素の概要を示します。
この基準には、次の項目が含まれる必要があります。
- 意図される機能要件と非機能要件
- 機能のネガティブなシナリオ
- パフォーマンス ガイドライン
- 適切なユーザー ワークフロー
- その他の機能への影響
- ユーザー エクスペリエンス
会議登録をテスト ケースの例として使用しましょう: ユーザーが連絡先情報を含むフォームを送信し、支払いオプションを選択し、確認が画面に表示され、電子メールで送信されます。これらは受け入れリストの一部になります。また、テスト ケースでは、ユーザー エクスペリエンス (UX) の容易さとフローも考慮します。ユーザー ストーリー自体と同様に、テストされる詳細な量は、機能が価値を提供するために必要なもののみを反映します。
強力なユーザー ストーリーを作成するメリット
製品マネージャーや開発チーム メンバーの中には、要件リストの代わりにユーザー ストーリーを書くことは、アジャイル プロセス全体にステップを追加するような気がします。しかし、ユーザー ストーリーの主なメリットは、共同作業に依存し、全員に情報を提供し、同じページに残す点です。開発プロセスでは、発見や関係者のフィードバックを通じて物事が変化する可能性があり、その結果、ユーザー ストーリーはこのような状況に変化したり適応したりします。
最も一般的なメリットには、次のようなものがあります。
- 全体像をより小さなプロジェクトに分割して、進捗をすばやく示します。
- チームのモチベーションを高め、迅速な成功を収め、プロジェクトを前進させます。
- エンド ユーザーを第一に考え、それによってユーザーの受け入れと満足度の向上を促進します。
- 価値の高い機能に優先順位を付けます。
- クリエイティブなソリューション プランニングを可能にするコラボレーション型の会話を行うプラットフォームを提供します。
- チームが結果に集中し続け、より良い全体的な製品を生み出す、高レベルの協力を促します。
優れたユーザー ストーリーを書く方法
大規模なソフトウェア イニシアチブの開発は、古い学校に行くことで成功と効率を享受しているのは直感に反するようです。 さまざまな色のシンプルな 3x5 カードと永続的なマーカーは、アジャイル開発プロセスに背景情報をもたらすユーザー ストーリーを作成するための謙虚な基礎となります。小さなカードは、チームの共同作業を通じて発見された、福利厚生に基づく基本的な説明を促します。
すべてのユーザー ストーリーはユニークで、ストーリー マップ、図、ストーリー ボード、モックアップで補完する必要がありますが、以下は効果的なユーザー ストーリーの作成に役立ついくつかのベスト プラクティスです。
- ユーザーを知る: ユーザー ペルソナを定義し、理解します。
- すべての関係者を含める: ユーザー ストーリー作成プロセスには、関連するすべての関係者を必ず含めます。テスト チームはストーリーを洗練させることさえできるかもしれません。
- ユーザーに焦点を当てる: ユーザーの視点からの議論と会話は、コンテキストと「完了」を構成するものの定義を提供します。
- 短くシンプルにする: 各ユーザー ストーリーに含まれる機能を 1 つだけ記述します 。ストーリーが大きすぎて短期間に開発できない場合は、より小さな増分に分割するか、機能を制限する特定の条件を追加できます。経験則として、ユーザー ストーリーは、開発チームが 1 回のイテレーションで完了できるほど小さくする必要があります。
- ディスカッションとコラボレーション: プロジェクトの規模、最低限実行可能な製品 (MVP)、誰がそれを使用するのか、何をするのか、そしてそれが包摂と範囲に関する決定に価値をもたらす理由に関する議論。
- 技術的な詳細を避ける: 技術的なタスクや「構築方法」の記述は、創造性や共同作業を妨げる可能性があるため、ユーザー ストーリーに書き込まないでください。技術的な詳細はプロセスの後半で行われ、開発者、テスター、システム アーキテクトによって組み込まれます。テンプレートは、技術的な詳細から離れてガイドするのに役立ちます。
- 3 Ws に焦点を当てる: 誰がそれを使用するのか、それが何であり、なぜそれが重要なのか。
- 視覚化を促す: 完成した製品を視覚化するために適切な方法 (図面、ストーリーとインパクトのマッピング、ストーリー ボード、モックアップ、プロトタイプ) を使用します。
- 価値とメリットを明確にする: ストーリーの目的が明確で、緊急性が示され、ストーリーが完成していることを確認します。
ユーザー ストーリーを作成する上での課題とよくある落とし穴
ユーザー ストーリーは、誰が機能を使用するのか、その機能が何をするのか、なぜその機能が重要なのかなどの質問に答えます。ストーリーの詳細は、ビジネス コンテキスト、ユーザー価値を提供し、チーム ディスカッションを促進します。ユーザー ストーリーを作成する際の一般的な課題は、ストーリーが価値を明確にするのに十分な包括的でありながら、スプリント (通常は 1 ~ 4 週間) など、短期間で提供できるほどシンプルであることを確認することです。このストーリーには、どのように構築されるか、指示をコーディングする方法の技術的な詳細は含めてはいけません。これらの詳細は、開発のこの時点では必要ありません。
ストーリーが大きすぎる場合や大きすぎる場合は、小さな部分に分割できます。
ここに良い例があります:
- 銀行の顧客として、請求書の支払いを計画できるように、バランスを確認できるようにしたいと考えています。
詳細やその他の機能を追加するのは魅力的かもしれませんが、それは扱いにくい物語を作成します。この種のストーリーは、次のようになります。
- セールス マネージャーとして、1 年間の予算を設定できるように、予測、売上、人事レポートを取得したいと考えています。
この例には、複数のコンポーネント (予測、売上、人員の個々のレポートを生成する) があり、複数の小さなユーザー ストーリーに分割する必要があります。
また、「完了」を構成するものを特定する受け入れ基準も必ず含めます。前述のとおり、受け入れ基準は、多くの場合、ユーザー ストーリー カードの裏面にチェックリストとして書かれています。
受け入れ基準を作成する際のその他の課題は次のとおりです。
- 構築方法に焦点を当てる自然な傾向。しかし、この技術的な詳細を対話から外しておくことで、より有意義な会話が生まれ、クリエイティブな解決策につながるだけでなく、ユーザーや非技術的なチーム メンバーもディスカッションに含めることもできます。
- ダイアログや会話には時間がかかり、忘れ去られることが多いため、ユーザー ストーリーのプラスの影響を制限します。
- データが不足したり、ユーザーやペルソナを本当に理解したりすることは、エンド ユーザーの手に渡されたときに機能の受け入れを危険にさらします。
- ストーリーを最小の増分に制限するのは簡単ではありませんが、詳細が多すぎると、ユーザー ストーリーが扱いにくくなります。
- 受け入れ基準や顧客のメリットなど、重要な情報を残しておくと、開発プロセス中に質問に回答が残る可能性があります。
Mike Cohn 氏の著書『User Stories Applied for Agile Software』は、「ソフトウェア要件はコミュニケーションの問題」というシンプルな観察で、ソフトウェア開発の中核となる問題を特定しています。
ソフトウェア開発やアジャイル手法に関連する技術言語は、多くの人にとって障害となる可能性があります。開発プロセスを通じて、ユーザー ストーリーを作成するには、オープンなダイアログと会話が組み込まれており、タスクを分割して勢いを維持し、完了の強力な定義を提供します。ソフトウェアの構築は、多くの関係者と大きな期待を持つ、大規模で時間のかかるプロセスです。しかし、いくつかのシンプルなガイドラインと昔ながらのテクニックに従うことで、ソフトウェア構築の複雑な部分がチーム全体に見え、最終的には実行可能なものになります。
ソフトウェア開発のためのSmartsheetを使用したユーザー ストーリーのマスター作成
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。