無料ユーザーストーリーテンプレート
以下のテンプレートは、様々な目的に使用できます。 ユーザーストーリーのバックログの作成・マッピング・管理と壮大な物語（エピック）の作成などが可能です。 これらのテンプレートの多くは類似しているため、個人の好みに応じて、または貴方の会社独自のプロセス (したがって、フォーマット) に従って選択してください。.
製品及びプロジェクトのマネージャーは、バックログテンプレートを使って、ユーザーストーリーを追跡しでき、さらに他のテンプレートを使ってユーザー ストーリーを作成又はマッピングできます。 他のチームのメンバーは、ユーザーストーリーやエピックのテンプレートを使って、ユーザーストーリーを作成できます。
ユーザーストーリーテンプレート
ユーザーストーリーは、製品諸チームが引き続きユーザーニーズに注目し、機能開発時に自らの作業管理を行うのに役立ちます。 プロジェクトとプロダクトのマネージャーたちは、このテンプレートを使って、ユーザーにより生成された作業の管理を行うことができます。 他のチームメンバーは全員、それを使って、ユーザーストーリーを作成できます。
ユーザーストーリーのバックログテンプレート
製品開発イテレーション（繰り返し）中にユーザーストーリーのバックログを管理するためには、このテンプレートを使って下さい。
バックログはスプリントプランニング中、チームがプロダクトバックログのトップアイテムを選択し、スプリントにそのアイテムを追加する時に作成されます。 バックログには、開発工程に組み込まれた全ての作業が含まれ、現在のイテレーションで完成すべきアイテムのTo-Doリスト（タスク一覧）です。 このリストは最終版でなければなりません (すなわち., この時点では、タスクの追加・削除はできません)。.
テンプレートには、バックログアイテム、ストーリーポイント、責任、ステータス、並びに元の予想の列があります。 日数を表わす列1〜5では、プロダクトマネージャーやプロジェクトマネージャーが、タスクに必要な毎日の開発追加時間数を書き込むことができます。 スプリント内のすべてのタスクに対する毎日の追加開発時間の合計量が合計行に表示されます。 そして、バーンダウンチャートには未解決の作業が表示されます。
ユーザーストーリーのマッピングテンプレート
これは、付箋（ポストイットノート）またはインデックスカードを使って、完成または再現できるテンプレートです。 ボックスの数は、特定のシステムの使用時に実行される活動によって異なる場合があります。
プロジェクトマネージャーとプロダクトマネージャーは、このテンプレートを使って、システム使用時のユーザー体験を活動順に並べることができます。 y 軸は、マッピングされる機能の精巧さの増減を表わします。 x 軸には、システム使用時のユーザー体験が発生順（シーケンシャル）で並べられた表が含まれます。 最初の行には最も基本的な機能が含まれており、後続の行はより複雑になります。
エピックテンプレート
１つのエピックは、開発すべき機能を扱う作業のチュンク（塊）であり、複数のエピックをユーザーストーリーの生成に使うことができます。 エピックを作成のためにはこのテンプレートを使ってください。 次に、各エピックから生成されたユーザー ストーリーをトレースします。 プロジェクトマネージャーとプロダクトマネージャーは、このテンプレートを使ってエピックにより生じた作業の管理ができ、他の全てのチームメンバーがこのテンプレート使ってエピックを作成できます。
ユーザーストーリーとは何ですか?
ユーザーストーリーとは、 通常はアプリやウェブサイトといった開発中の製品 とのインタラクション（相互作用）に関する短く単純な特殊な記述 (1又は2文)です。 (もちろん、ユーザーストーリーは他のプロジェクトの開発にも利用できます。) ユーザーストーリーは、開発者、デザイナー、プロダクトマネージャーさらにそれ以外の製品構築に関わる人々を導くフレームワークとして使用されます。
ユーザーストーリーでは、ユーザーが誰で、問題の製品又はサービスで何をするのかを定義する必要があります。 また、ユーザーストーリーには、ユーザータイプ、そのユーザーの望むアクション、そのアクションの完了時にユーザーが取得する値も含まれます。 ただし、ユーザーストーリーには、一定の性能・機能の実行や開発方法が記述されるべきではありません。
ユーザー ストーリーは、 アジャイル ソフトウェア開発手法に不可欠な要素です。 従来のプロジェクト管理手法と（例えば ウォーターフォール)比較すると、アジャイルはフレキシブル（柔軟）でインタラクティブ（相互作用性のある）なプロセスです。 アジャイルはイテレーションと呼ばれるサイクルで実行 され、1〜4週間続きます。 開発者はイテレーションごとに、新機能の作成や既存の機能の改良に取り組みます。 ユーザーストーリーは、機能作成方法のガイドとして利用されます。 以下の無料のダウンロード可能なテンプレートは、アジャイルプロセスのさまざまな工程で、ユーザー ストーリー作成及び操作用に使用することができます。 こちらからアジャイルに関する詳細はご覧になり、アジャイルプロジェクト管理テンプレートを無料でダウンロードすることができます。
スクラムとは何ですか?
スクラム は、広く使用されているアジャイル手法のバリエーションの1つです。 この2手法間にはいくつかの違いがあります。 スクラムとは、進捗状況や計画について話し合う、毎日の短いチームミーティングを指します。 スクラムでは、サイクルは イテレーションではなくスプリントと呼ばれ、許容基準は 完了の定義 (DOD) と呼ばれます。 しかしながら、スクラムとアジャイルはハイレベル原則を共有しています。
ユーザーストーリーの構造とは何ですか?
アジャイルのユーザーストーリーには特定の形式ではないので、多くのバリエーションがあります (ただし、用語使用が若干異なるだけです). ユーザーストーリーの基本的な形式は、問題の製品の特定のユーザーの視点から、ユーザーがその製品で何がしたいのか、さらに、その機能の実行でユーザーが獲得したいと考える価値が何であるかを説明します。 私がしたいと思うから
ユーザーストーリーの作成方法?
ユーザーストーリーはエピックから取り出 されることが多く、エピックは、ユーザーストーリーと類似の形式を使います。 しかしながら、エピックはよりハイレベルで、複数の機能を装備します。 (エピックは短い表現で表わすこともできます.) エピックは 1 つのアジャイルイテレーションで完成するには大きすぎるため、分割する必要があります。 アイデアは、エピックから何かを消去するためではなく、1 回のイテレーションで完了できる程ラフなユーザー ストーリーを作成するために使います。 カレンダーアプリ用エピックの例には、以下のようなものが含まれます。
- ユーザーとして、私は自分の携帯電話からすべての予定を管理したいと考えています。
- ユーザーとして、家族カレンダーとビジネスカレンダーを一緒に見たいと思っています。
- ユーザーとして、アプリを開かずにリマインダーに完全な機能を備えたいと考えています。
最初はエピックとユーザーストーリーの区別が難しい場合がありますが、経験を積んでも簡単になります。
エピックとユーザーストーリーは、推測ではなくユーザーのニーズを基本にしている必要があり、ユーザーあるいは潜在的ユーザをインタビューして、そのストーリーが確かに事実に基づくよう配慮します。
多くの組織でも、ユーザーストーリー作成時にペルソナも使用しています。 ペルソナ とは、一般的な想像上のユーザーではなく、特定のユーザータイプにデザイナーと開発者が注目するための仮想ユーザーの短い伝記です。
組織によっては、 必要な作業を単一のイテレーションに合わせるためユーザーストーリーを子ストーリー (別名サブストーリー) に分割します。 しかしながら、ユーザーストーリーを分割できるならば、あるいは、1イテレーションに適合しないならば、それは実際にはエピックであると考える人もいます。
ユーザーストーリーを作成するのは誰ですか?
プロジェクトのメンバーは誰でも、プロジェクト期間中いつでもユーザーストーリーを作成できます。 一般的には、ストーリー作成セッションは最初のイテレーションの前に行われます。そして最初のイテレーションによりプロダクトチームは取り組むべきストーリーのバックログを獲得できます。 ユーザーストーリーを作成するプロセスの詳細 については、こちらをご覧ください。
強力なユーザーストーリーの作成に役立つフレームワークがいくつか用意されています。 これらのフレームワークの中でも最もよく知られているものの1つが、コンサルタントで開発者のビル・ウェーク（Bill Wake） が作ったINVEST と呼ばれるニーモニックです。
- 独立性： それは自己充足型である必要があります(すなわち., 別のユーザーストーリーに依存しません).
- 交渉の可能性： 議論の余地があるはずです。
- 価値性： ストーリーは関係者に価値を提供する必要があります。
- 推定の可能性： ストーリーの機能を実行するための労力の総量は推定可能です。
- 小型化： 1つのスプリントで完了される必要があります。
- テストの可能性： 複数のナラティブアドレス機能の確認テスト作成のためストーリーには十分な詳細が含まれる必要があります。
ユーザーストーリーの恩恵はは何ですか?
ユーザーストーリーは、価値を提供し、ユーザーのニーズを満たす機能構築という最終目的に向かった製品開発チームの取り組みのお手伝いをするので、アジャイルやその他の手法で人気を集めています。 以下に、ユーザーストーリーの恩恵をいくつか紹介します。
- それは、新性能・将来性が必要なことを知る簡単な方法です。
- ユーザーストーリーは顧客の問題解決に必要な機能を明らかにします。
- ユーザーストーリーは理解し易く、覚え易いです。
- ユーザーストーリーは、ビジネス価値と顧客ニーズに焦点を当てます。
- ユーザーストーリーは優先順位付けを簡易化します。
- ユーザーストーリーは潜在的顧客が製品をどのように使用するかに焦点を当てます。
- ユーザーストーリーは起動の失敗が非常に少ないため、時間を節約できます。
- ユーザーストーリーは各イテレーションでの性能追加を追跡することにより、製品履歴を追跡にも利用できます。
- ユーザーストーリーは要件書き込みから、要件の語りに焦点を移しています。
- ユーザーストーリーは詳細レベルで異なる場合があります。
- 作業を複数チャンク（塊）に分割することで、実行がフレキシブルになります。
- 技術的な仕様は開発者に任されています。
- ユーザーストーリーは協力と創造的解決を推進します。
- ユーザーストーリーはROI（投資利益率） とチームの士気を向上させます。
ユーザーストーリーの今後の挑戦課題は何ですか?
ユーザーストーリーは、他のビジネスツールやプロセスと同様に役立ちますが、完璧ではありません。 以下に、関連する今後の挑戦課題をいくつかご紹介します。
- ユーザージャーニー、ビジュアルデザイン又は技術的要求事項には対応していません。
- ユーザーストーリーの最終条項は、プロセスの最も重要な部分であるにもかかわらず、ライターによって無視されることがよくあります。
- ライターが適切なデータを持っていない、又は、ユーザーのニーズを引き出すために取得したデータを研究しなければ、ユーザーストーリーは弱くなります。
- ユーザーを完全に理解していないと、実際のニーズにそぐわないストーリーになります。
- 製品チームが適切な専門知識を持っていない場合、ユーザーストーリーはユーザーニーズの処理に効果的ではないでしょう。
ユーザーストーリーの実行手段?
ユーザーストーリーは、チームディスカッションのスタート地点となります。 このディスカッションでは、ユーザーにとって価値のあると言われる機能の実行方法に関する詳細とそれに特有なアイデアをいくつも生成する必要があります。 ペルソナ（ユーザー像）を作成した場合、ユーザー中心の焦点を維持するために、これらのディスカッションでペルソナを使うと有益です。
ディスカッション中は、StoriesOnBoardやFeatureMapなどのツールを使って、ユーザーストーリーをプロダクトキャンバス上にペルソナ、エピック並びにその他の関連アイテムと一緒に表示することができます。 また、低解像度のモックアップ（実物大模型）を作成して、ユーザーストーリーで提起された問題の解決策提供機能を一通り見直すチームもあります。
ユーザーストーリーが作成され議論された後、ユーザーストーリーをマッピングする必要があります。 マッピング とは、ユーザーが完了する性能・機能又はタスクに関連する複数の論理グループ中にユーザーストーリーのグリッドをレイアウトするプロセスです。 各グループはテーマと呼ばれることもあります。 ユーザー ストーリーのマッピングには、付箋に書き込んだり、壁に貼ったり、あるいはインデックス カードで埋まったボックスを用意しテーブル上にそれらのカードを広げるなど、多くの手法があります。 ユーザーストーリーマッピングの詳細 はこちらをご覧ください。
前述のとおり、ユーザーストーリーはバックログに収集されます。 バックログ は、製品向けに作成される機能性の優先順リストです。 プロダクトオーナーは、イテレーション（繰り返し）のたびにバックログに十分なユーザー ストーリーを確保する責任があります。 組織によっては、自らのバックログで他のアイテムを使用しますが、ユーザーストーリーが最も人気のあるアイテムです。
ウォーターフォールプロジェクト管理では、最終製品の特徴と機能の概要が仕様書にまとめられています。 ユーザーストーリーは真の要求事項ではありませんが、アジャイルプロジェクト管理では、バックログが仕様書と同様の目的を果たします。
その構造により、アジャイルのバックログはウォーターフォール仕様書のバックログよりもはるかに流動的です。 バックログのストーリーには、ストーリーの起源から開発・テスト・リリースに至るまでトレーサビリティを容易にする特有の識別名が与えられる必要があります (例., バグレポート、ユーザーインタビュー、サポートチケット、開発者からの提案など)。 新製品発売（ローンチ）を通じてストーリーを追跡するための共通ツールには、JIRA、GitHub、FogBugz、あるいはExcelのスプレッドシートなどがあります。
チームが最初のストーリーについて合意した後、開発・テスト・その他のプロセスステップ（工程段階）に必要な残りの情報を具体化するためにミーティングを行う必要があります。 また、ユーザー ストーリーに記載されているどの機能が最初に開発されるのか優先順位を付ける必要もあります。 また、アジャイルの構造により、優先順位付けは流動的であり、ユーザーの新たなニーズ、新しいユーザーストーリー、さらには新しい競争圧力に応じて変化します。
ユーザーストーリーが完了したことがどうすれば分かりますか?
どんなストーリーでも、目的の機能が正常に実行されているかを確認する手段が必要になります。 これを表すために使われる2つの表現があります。すなわち、許容基準 と 充足条件があります。 専門家の中には、この2つの用語は同義であると言う人もいます; 充足条件は、許容基準よりも高い水準であると考える人、充足条件が満たされていることを確認するために許容基準の詳細が使用されていると考える人もいます。
ユーザーストーリーは誰が利用しますか?
アジャイルチーム全員がプロジェクトでの彼らの作業にユーザーストーリーを使うことができますが、ここでは鍵となるチームメンバーのリストをご紹介します。
- プロダクトオーナー： ユーザーニーズを満たす製品の納入を保証します。
- 開発者： チーム作業を指導しましょう。
- テスター： 予想通りに製品が機能しているかを確認します。
- テクニカルライター： サポート資料に重要なユースケースが含まれることを保証します。
開発者を除き、これらの人々はそれぞれ顧客代理として行動でき、顧客又はユーザーの役割に彼らを当てはめることができます。
ソフトウェア開発向け Smartsheetを使ったユーザーストーリー作成改良
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。