注:ウェブサイトは自動的に翻訳されている。最高の読書体験のために英語に切り替える。

アジャイルにおけるユーザーストーリーとは何か

スクラムにおけるユーザーストーリー:知っておくべきことすべて

目標は明確だ。顧客に高い付加価値を提供する製品を開発したい。チームメンバーや利害関係者が満足する結果を得たい。しかし、どうやってこの目標を達成するのか?どうすれば、製品のすべての要件を小さなステップで徹底的に満たすことができるのだろうか? 

Agileでは、ユーザーストーリーがそのための効率的なツールであることが証明されている。ユーザーストーリーは、最初のアイデアから販売準備の整った製品まで、段階を追ってあなたを導いてくれる。ユーザーストーリーとは何か、どのように作成するのか、そしてどのようにユーザーストーリーから利益を得ることができるのかを紹介する。

 

Agileにおけるユーザーストーリーとは何か?

Agileにおけるユーザーストーリーの定義は、ユーザーの視点から見た製品の要求を記述するものである。言い換えれば、ユーザーストーリーは、製品がどのような特徴や機能を持つべきかを伝えるものである。そのため、ユーザーのニーズを議論・検証し、共通理解のもと実装に取り組むための中心的なツールとなる。 

ユーザーストーリーは、チームメンバー、利害関係者、顧客が理解し、話す普遍的な言語を提供する。実際には、これは、誤解の余地をほとんど残すことなく、顧客が望む製品の理解を深めるためにユーザーストーリーを使用できることを意味する。 

いくつかのユーザーストーリーをまとめてユースケースとする。 ユーザーストーリーの起源はAgileソフトウェア開発にある。

 

アジャイルのユーザーストーリーはどのように構成されるのか?

ユーザーストーリーは、顧客やユーザーの視点から作成されるプロジェクトの結果に対する要求や希望を記述する。アジャイルなユーザーストーリーは、このような基本構造を持つ:

WHO (役割)を望んでいる。 (目標/願望) なぜだ (付加価値)か?

ユーザーストーリーの個々の構成要素を詳しく見てみよう:

WHO (USER)

WERのプレースホルダーには、顧客やターゲットグループの典型的な代表者を記入する。ユーザーAgileストーリーのWHOをどの程度詳細に記述するかは、ユーザーストーリー自体やプロジェクトの進捗に依存する。従って、意味のあるユーザーストーリーを作成するために十分詳細に記述すること。

なに

ここにユーザーの希望を置く。ユーザーが何を期待し、何を必要としているかを自問することができる。製品がまだ開発初期段階であれば、ユーザーがどのような機能を期待しているのか、経験に基づいて仮説を立てることができる。すでに同じような製品を市場に出している場合は、その製品に対するフィードバックから期待する機能を導き出すこともできる。

なぜ(付加価値)

付加価値だけが、なぜその機能がユーザーにとって重要なのかを示す。したがって、WHYでは、顧客の要求をどれだけ理解しているかを正直に振り返ることができる。なぜなら:例えば、顧客がそれを望んでいると表明したからといって、ユーザーストーリーに要件を盛り込むのは簡単である。しかし、顧客がなぜそれを必要とするのかを理解して初めて、その要件を実装するためのコンテキストができる。そうして初めて、顧客の提案/要求が効率的に彼らの本当のニーズ–を満たしているのか、それとももっとスマートな方法があるのかを問うことができる。例を見てみよう: 

顧客がサイクリング用のレインケープを欲しがっている。したがって、「レインケープ」という要件を含めることができる。あるいは、なぜレインケープが必要なのかを顧客に尋ねることもできる。顧客が「濡れたくないから」と答えたとしよう。 

つまり、必ずしもレインケープを用意する必要はない。屋根一体型の自転車を提供することもできる。重要なのは、雨に濡れないという顧客のニーズや問題–を解決することである。なぜ」を理解すればするほど、ユーザーストーリーをよりよく設計することができる。

ほとんどのAgileコーチは堂々巡りをしている......。

...そして表面的な症状を治療する。今こそ心理学–を使って、持続可能な意識改革を行う時なのだ。

"多くのチームメンバーはあえて発言しない!"

"予期せぬ問題やバグを発見するのが遅すぎる!"

「簡単なレトロスペクティブの準備に何時間もかかることがあるのはなぜだろう?

Agileにおけるユーザーストーリー(例)とは何か?

これで、Agile ユーザーストーリーの個々の構成要素がわかった。Agileユーザーストーリーの例は次のようになる: 

として お客様 私はそうしたい。 安全なパスワード, 私の顧客データが守られるように。

以下がその内容である。顧客" ユーザー、"安全なパスワード" 関数と"顧客データが守られるように 付加価値である。 

 

スクラムにおけるユーザーストーリーとは何か?

スクラムでユーザーストーリーを扱うとき、受け入れ基準を追加する。受け入れ基準は、ユーザーストーリーが受け入れ時に満たすべき技術的要件を記述する。言い換えれば受け入れ基準は、ユーザーストーリーが価値を生み出すために必要な要件である。

バックログにおけるAgileユーザーストーリーの意味はもっと区別できる。なぜなら:バックログでは、ユーザーストーリーは要求を記述するだけでなく、特別な階層タイプを表すことができる。この3つの階層タイプがある:

叙事詩だ: エピックとは、製品の機能領域を広く定義したもので、その具体的な範囲はまだ不明確かもしれない。

特徴だ: フィーチャーとは、叙事詩における特定のパフォーマンス特性のことである。

ストーリーだ: ストーリーは、技術的なAgileユーザーストーリーと機能内のユーザーストーリーである。

これらの階層タイプはスプリント内で実装することができる。これらはユーザーに具体的な利益をもたらす。 

 

ユーザーストーリーを書く – 説得力のあるユーザーストーリーを作るには?

アジャイルプロジェクトマネジメントで役に立つユーザーストーリーを書くためには、すべてのステークホルダーとの詳細な話し合いが重要である。これらによって、ターゲットグループと作成する製品について包括的な理解が得られるはずだ。そこから、例えばペルソナを導き出すことができる。 

加えて、いわゆる インベスト基準説得力のあるユーザーストーリーを作るためだ:

独立系だ: ユーザーストーリーは他のユーザーストーリーから独立していなければならない。つまり、ストーリーの実装は、他のストーリーが事前に実装されていることを前提にしてはならない。これは、いつでもユーザーストーリーの優先順位をつけたり、バックログから削除できるという利点がある。 

自転車の例をもう一度見てみよう。顧客がもう濡れないように、雨よけの代わりに自転車のサドルに小さな屋根を取り付けることにしたとしよう。これがユーザーストーリーになる。しかし、屋根をつけるためには、まず屋根を取り付けることができる、より安定したサドルを開発しなければならない。それは別のユーザーストーリーだ。両ストーリーは互いに積み重なる。これはまさに防ぐべきことだ。

もちろん、あるユーザーストーリーを他のユーザーストーリーより先にやらなければならないのは、やむを得ない場合もある。しかし、一般的なルールとして、他の20のユーザーストーリーを最初に実装しなければならないユーザーストーリーは避けること。

交渉可能だ: ユーザーストーリーを書くのは、時にかなり時間がかかることがある–。ということだ: プロダクト・オーナーステークホルダーと開発者は、常に一緒に議論し、ユーザーストーリーを洗練させるべきである。 

貴重なものだ: アジャイルプロジェクトマネジメントにおけるユーザーストーリーの結果は、顧客にとって付加価値がなければならない。

推定可能だ: 説得力のあるユーザーストーリーによって、開発チームはそれを実装するためにどれだけの労力がかかるかを見積もることができる。

小さい: ユーザーストーリーは、1スプリントで実現できるほど「小さな」ものでなければならない。

テスト可能だ: スクラムにおけるユーザーストーリーはテスト可能でなければならない。これが、実際に実装できるかどうかをチェックする唯一の方法である。

 

Agileにおけるユーザーストーリーの活用法

もしあなたがAgileでユーザーストーリーを書くことに慣れていなければ、余計な作業のように思えるかもしれない。しかし、ユーザーストーリーはチームにタスクの重要なコンテキストを提供し、各タスクの重要性をより明確にする。

基本的に、これがユーザーストーリーの利点だ:

ユーザー重視である: ユーザーストーリーは、問題指向のToDoリストのようなものだ。あなたのチームはそれを使ってタスクを管理し、ユーザーのニーズを満たす方法を正確に知ることができる。

ホリスティックな協力だ: ユーザーストーリーは、関係者全員に、物事がどこで進んでいるかを一目で示す。こうすることで、全員が協力し合い、ユーザーが特に高い付加価値を受け取る方法を何度も決定することができる。 

創造的な解決策だ: Agileソフトウェア開発でユーザーストーリーを作成する クリエイティブな結果.なぜなら、最終製品に最適な解決策について、チームに批判的に考えさせるからだ。

一貫した成功: 各ユーザーストーリーは小さな挑戦である。そのため、チームは各ストーリーの後に小さな成功を祝うことができる。これは開発プロセス全体を通してモチベーションを高める。

 

結論

ユーザーストーリーは、アジャイルチームの作業において重要なツールである。ユーザーストーリーは、誰のために何をなぜ開発するのかを何度も詳細に示す。これは、ターゲットグループに合わせた高品質の製品を作るのに役立つだけでなく、プロセス全体を通してチームのモチベーションを維持するのにも役立つ。 

アジャイル・ワーキングというマクロ・レベルで成功するためには、組織全体がアジャイルに考え、機能する必要がある。これを支援するために、私たちは著名な専門家たちと協力して以下のものを作成した。 プロジェクト・スカジャイル 設計されている。これは、様々なウェビナーで、アジャイル変革に正しくアプローチする方法を示している。トレーニングは無料だ。気軽に見てみよう!

振り返り用の質問をもっとバリエーション豊かにしたい場合は、こちらの記事をご覧いただきたい: 初心者とプロのための54の新鮮な回顧的手法 (マリオ・カート・レトロ、マラソン・レトロ、イーロン・マスク・レトロなど)。

を手に入れる最良の方法のひとつである。 チームメンバーのアジャイル・マインドセットを持続可能な方法で開発する。 ところで、アジャイルHealth Checkの実装である。我々の 無料Team-Health Checkコンストラクション・キット –をクリックするだけで、適切な質問をすることができる。

この記事をネットワークで共有する

チームを盛り上げる必要があるか?こうしよう: スポティファイHealth Checkレトロスペクティブ!

初めての健康質問: "😍 僕らは仕事に行くのが楽しいし、一緒に働くのがとても楽しいんだ」。

もっと見たい?レトロツールを試してみよう。

その他の記事

Echometerニュースレター

Echometerの最新情報をお見逃しなく。