例とテンプレートで作るユーザー ストーリー

要約: ユーザーストーリーは、ソフトウェアの機能をエンドユーザーの観点から、堅苦しくない一般的な言葉で説明するものであり、ソフトウェアの機能が顧客にどのように価値を提供するかを示すことを目的としています。

ユーザーストーリーとはソフトウェアのシステム要件であると簡単に説明されていることがあります。ところが実際はそうではありません。

アジャイルソフトウェア開発で重要なのは、人を第一に考えることです。ユーザーストーリーでは、実際のエンドユーザーを中心に考えます。このようなストーリーでは、開発チームとその作業に関連するコンテキストを伝えるため、技術的な用語の使用を避けます。ユーザーストーリーを読んだチームは、自分たちが何のためにどのような仕事をしているのか、そしてそれによってどのような価値が生み出されるのかを理解できます。

ユーザーストーリーはアジャイルプログラムの主要な要素です。ユーザーを重視し、コラボレーション、創造性、製品の総合的改善を推進する日常業務のフレームワークの構築に役立ちます。

ユーザーストーリーは、アジャイルフレームワークの最小作業単位です。これは機能ではなく、ソフトウェアユーザーの視点に基づく最終目標です。

ユーザーストーリーは、ソフトウェアの機能をエンドユーザーや顧客の観点から、堅苦しくない一般的な言葉で説明します。

ユーザーストーリーの目的は、作業によって特定の価値を顧客に提供する方法を示すことです。「顧客」は、従来のように外部のエンドユーザーを指すとは限りません。内部の利用者やチームの同僚を指す場合もあります。

ユーザーストーリーとは、目指す成果を簡潔に記述したものです。詳細は記載されません。要件は、チームで合意された後に追加されます。

ストーリーは、スクラムやカンバンと同様にアジャイル フレームワークにぴったりと適合します。スクラムでは、ユーザー ストーリーがスプリントに追加され、スプリントの期間にわたって「バーン ダウン」されます。カンバン チームはユーザー ストーリーをバックログに取り込み、ワークフローを適用します。ユーザー ストーリーをこのように処理することで、スクラム チームによる見積もりとスプリント計画が改善され、予測の精度とアジリティが向上します。ストーリーにより、カンバン チームは進行中の作業 (WIP) の管理方法を学び、ワークフローをさらに改善できます。

ユーザー ストーリーは、エピックやイニシアチブなど、より大きなアジャイル フレームワークのビルディング ブロックでもあります。エピックは一連のストーリーに分割される大きな作業項目であり、複数のエピックがイニシアチブを構成します。これらの大きな構造により、(店舗の) 開発チームの日常的な作業を、エピックやイニシアチブに組み込まれた組織目標の達成に繋げられます。

エピックとイニシアチブの詳細を見る

アジャイルになじみのない開発チームにとって、ユーザーストーリーは追加のステップのように感じられるかもしれません。大きなプロジェクト (エピック) を一連のステップに分割するだけでよいのでは、と思う人もいるでしょう。しかし、ストーリーはチームに重要なコンテキストを提供し、タスクとそれがもたらす価値を関連付けます。

ユーザーストーリーには、以下のような重要なメリットが数多くあります。

• ストーリーはユーザーに焦点を当てます。To Do リストのおかげで、チームは実行する必要があるタスクに集中できます。一方、ストーリーをまとめることによってチームは実際のユーザーが直面している問題の解決に集中できます。
  
• ストーリーはコラボレーションを実現します。最終目標を定義することで、ユーザーに最善のサービスを提供し、目標を達成する方法をチームが協力して決定できます。
  
• ストーリーはクリエイティブな解決策を生み出します。ストーリーにより、最終目標の達成に向けた最善の解決策をチームが冷静かつクリエイティブに考えられるようになります。
  
• ストーリーは勢いを生み出します。ストーリーを 1 つずつクリアすることで、開発チームは小さなチャレンジと成功を味わえるため、それが勢いにつながります。

Jira でのユーザー ストーリーの使用方法

ストーリーを作成したら、ワークフローに統合します。通常、ストーリーはプロダクト所有者、プロダクトマネージャー、またはプログラムマネージャーによって作成され、レビュー担当者に送信されます。

スプリントまたはイテレーション計画ミーティング中に、チームはスプリントで処理するストーリーを決定します。各ユーザーストーリーで必要とされる要件と機能について話し合います。それにより、ストーリーを技術と創造性によって実現できるようになります。合意された要件は、ストーリーに追加されます。

このミーティングのもう 1 つのステップが、複雑さや完了までの所要時間に基づくストーリーのスコア決定です。チームは T シャツサイズ、フィボナッチ数列、またはプランニングポーカーを使用して適切な見積もりを行います。ストーリーは 1 つのスプリントで完了できる規模にする必要があります。そのため、各ストーリーの詳細を決定するチームは、指定された完了期間を超過するストーリーがあれば必ず分割します。

ユーザーストーリーを作成する場合は次のことを考慮します。

• 「完了」の定義 — 一般に、ストーリーは概説されているタスクをユーザーがすべて実行できれば「完了」ですが、完了が何を意味するかは確実に定義しておくようにします。
  
• サブタスクまたはタスクの概説 — 完了する必要がある特定のステップ、およびそれらのステップの責任者を決定しておくようにします。
  
• ユーザーのペルソナ — 誰のために作成するかを考慮します。エンドユーザーが複数の場合は、ストーリーも複数作成することを検討します。
  
• ステップの順序付け — より大きなプロセスの中で、各ステップに対してストーリーを作成します。
  
• フィードバックの採用 — ユーザーの声に耳を傾け、問題やニーズを汲み上げます。顧客から情報が得られるのであれば、推測してストーリーを作り上げる必要はありません。
  
• 所要時間 — 所要時間は扱いにくい事項です。多くの開発チームは一般的に所要時間に関する議論を避け、見積もりフレームワークを拠り所にしています。ストーリーは 1 つのスプリントで完了できる規模にする必要があるため、完了に週または月単位の時間がかかるストーリーは、より小さなストーリーに分割するか、独自のエピック作成を考慮してください。
  

ユーザーストーリーが明確に定義されたら、必ずチーム全体に対して可視化します。

ユーザーストーリーの多くは、以下のような構造のシンプルな文で表されます。

「私が [ペルソナ] なら、[希望] を実行することで [目標] を達成したい」

これを細分化していきます:

• 「私が [ペルソナ] なら」: 誰のためにこれを構築しますか? 単なる役職ではなく、個人のペルソナを対象とします。たとえば、この個人を Max とします。Max がどのような人物であるかについての理解をチームで共有する必要があります。できれば多くの Max にインタビューしたいところです。どのように仕事をするか、どのように考えるか、どのように感じるかを理解します。Max に共感を持てるようにします。
• 「希望」: ここには使用する機能ではなく、意図を記述します。実際に達成しようとしているものは何ですか?この記述は導入を意図したものではありません。UI について記述し、ユーザーの目標を記述していないようであれば、それは適切ではありません。
• 「目標」: 何かをしたいという現在の希望が全体像の中でどのように位置付けられますか? 達成しようとしている全体的なメリットは何ですか? 解決する必要のある大きな問題は何ですか?

たとえば、ユーザーストーリーは次のようになります:

• 私が Max なら、友達を招待してこのサービスを一緒に受けられるようにしたい。
• 私が Sascha なら、仕事を整理して、上手に管理できていると思えるようになりたい。
• 私が管理者なら、部下たちの作業の進捗を把握できるようにして、成功や失敗についてより適切に報告できるようになりたい。

この構造は必須ではありませんが、完了の条件を定義するのに役立ちます。ペルソナが希望する価値を得られれば、ストーリーは完了します。チーム独自の構造を定義し、それに従うことをお勧めします。

ユーザーストーリーは、開発チームメンバーが日常的な作業を行う理由とその背景を記述したもので、一般的にペルソナ + ニーズ + 目的として表現されます。チームが何を実現しようとしているのかだけでなく、その理由や背景も理解することが、プロセスを円滑に進めるうえで重要です。

まず、次のプロジェクト、または最も急を要する大きなプロジェクト (エピックなど) を評価します。それをより小さなユーザーストーリーに分割し、開発チームとともに精査します。ストーリーがチーム全体に公開されたら、作業を開始できます。