以前に、ユーザーストーリーの問題について既に書いた。 それから私にとって最良の解決策は、提案された製品の変更についてチームと話し合うことでした。 これは、チームが協力して製品が成熟したときにうまくいきました。 ただし、現在は新しいチームでゼロから新しい製品を作成するのに忙しくしています。 この場合、プロジェクトをゼロから開発しているため、顧客の動機、イベント、期待について誤解する問題に直面しています。 しかし、今日、すべてが変わりました。 GTDの哲学を使用して、機能をより適切に定義する素晴らしい方法を見つけました。
私はそれらをワーキングストーリーと呼びます。
どこから来たの
このアイデアは、インターコムの非常に頭のいい人たちによって発明されました 。 彼らが言うことは次のとおりです。
開始イベントまたは状況に焦点を当てて、作業の各設計問題を強調し、期待される結果は次のとおりです。
_____の場合、_____が必要な場合、_____ができます。
たとえば、重要な新規顧客がサインアップしたときに通知を受け取りたい場合、彼との会話を開始できます。
その投稿では、これは作業履歴と呼ばれていませんでしたが、後でその名前を使用します。 この記事ではこの概念にあまり注意を払っていないので、なぜそれが好きで、なぜカスタムストーリーよりも優れているのかを説明します。
ユーザーストーリーの問題（何度も）
要約すると、ユーザーストーリーの問題は、仮定が多すぎて因果関係がないことです。 タスクがユーザーストーリーの形式で表示される場合（[ユーザータイプ]として、[アクション]を実行して[結果]が必要です）、「理由」という質問の余地はありません。 。
そして、私はこの形式をどのように見ているのですか？
人工画像とアクションの間の仮定と矛盾
最初の問題は、人工画像から開始することです。これは非常に悪い考えであり、その後、予想される結果を得るために配置する必要があるアクションを設計します。 この図は、アクションと人工画像が組み合わされていないことを示しています。
既存のユーザーストーリーをさらに見てみましょう。
カスタムストーリーの作成例
誰かが「モデレーター」または「エバリュエーター」を読むと、上の表は本当に変わりますか？ 何かが追加されると、フローのあいまいさが生じます。 私とあなたは、モデレーターの意味、またはこの文脈でそれらがここに示されている理由をあなた自身の方法で解釈します。
以下を試してください。 最初の列全体を（As a / an-「誰かとして」-約翻訳者と呼ばれる）ドロップし、何かを失うかどうかを確認します。 以下のステートメントを比較してください。
モデレーターとして、名前とオプションの説明を入力して新しいゲームを作成したい
VS
名前とオプションの説明を入力して、新しいゲームを作成したい
空は地球に落ちなかったでしょ？
作業履歴：コンテキストと因果関係がボールを支配します
作業履歴の形式
2015年3月3日現在の更新：より多くの使用法とフィードバックに基づいて、今は少し異なる説明を使用しています。 これらのツイートで読むことができます。 この記事は後で更新します。
上の画像を見てください。 これですべてが整った！
因果関係に焦点を当てているため、上記の情報はすべて非常に重要で非常に有益です。 各作業ストーリーは、できるだけ多くのコンテキストを提供し、実装段階だけでなく、動機付けに焦点を当てる必要があります。
2015年6月4日の更新：しばらくWork Storiesで作業した後、MotivationをMotivation and Strengthに変更しました。 この資料と一致する記事 「作品のストーリーを書くための5つの有用なヒント」をご覧ください。 また、 このポッドキャストとこの短い記事で長所について詳しく知ることもできます。
上記のユーザーストーリーの表からいくつかの例をワークストーリーの形で書き直し、それぞれに動機付けとコンテキストを追加しましょう。
ユーザー履歴：
モデレーターとして、名前とオプションの説明を入力して新しいゲームを作成したいので、評価者を招待できます。
作業履歴：
鑑定士が私のゲームに入札する準備ができたら、彼らが理解できる形式でゲームを作成したいので、彼らは私のゲームを見つけて、彼らが価格を請求する理由を理解できます。
ユーザー履歴：
鑑定人として、私たちが大切にしている製品を見たいです。そして、評価のために与えられたものを知ります。
作業履歴：
評価したい製品を見つけたら、それを見て、適切な製品を評価していることを確認できます。
ユーザー履歴：
モデレーターとして、評価または再評価する製品を選択すると、チームが製品を確認して評価できるようになります。
作業履歴：
製品が評価されなかった場合、または評価に満足できなかった場合、評価プロセスを再開し、すべての人にそれを知らせることができれば、チームは評価が必要な特定の製品を知ることができます。
複数の役割とイベントはどうですか？
* 2014年7月28日追加：Work Storiesについて大きなフィードバックを受け取り、引き続き作業しているため、「When _ Condition are met」の一部としてロールまたはキャラクターを含めると便利な場合があります。
複数の役割の製品
役割/キャラクターは、製品に複数の役割がある場合、たとえばIT製品（管理者、マネージャー、メンバーなど）や市場製品（買い手、売り手）に最も役立ちます。 ポイントは、私たちが誰について話しているのかを明確にすることだけです。
例としてeBayを検討してください。
バイヤーが既に製品に入札している場合、彼はカウンター入札を逃すのではないかと心配しているため、すぐに高い入札についての通知を受け取り、自分自身の入札を評価して変更するのに十分な時間があるようにします。
原因と結果を持つ役割
ワークストーリーが複数の役割にすぐに影響を与える場合があります：原因と結果のシナリオの確立。
そして再び、eBayを例として考えてみましょう。
売り手が市場から製品を受け取って入札することに満足していない場合、既に入札を行った購入者は、製品が出荷されたという通知をすぐに受け取りたいので、購入者は製品を監視する必要がなくなったことを知ります、代わりに、他の同様の製品を探します。
ロールの代わりにイベントを使用する
確かに、イベントがすべてのロールまたはロールのグループに影響を及ぼす状況が発生する場合があります。たとえば、パスワードのリマインダーを受信する必要がある場合です。 この場合、特定の役割には意味がありません。 このイベントのコンテキストで、クライアントや他のユーザー（ユーザーではない）などの一般的な用語を使用して、それについて話すことがより重要です。
クライアントがモバイルデバイスで作業しているときにパスワードを忘れた場合、モバイルデバイスからのパスワード修正を容易にする方法でパスワードを受け取りたいと思うと、登録してニュースフィードにアクセスし続けることができます。
なぜユーザーではないのですか？ 後者は活気がなく、効果がないように見えますが、逆に買い手は、私たちに奉仕し、尊敬される必要がある聴衆がいることを思い出させます。
動機付けを定義するが、実装の段階を決定しない
実用的なストーリーは、動機付けとコンテキストについて考えさせ、追加された実装の役割を軽減させるため、優れています。 多くの場合、人々は「誰が」「どのように」というパラメータに集中しすぎているため、「なぜ」という意味を絶対に把握していません。 この「なぜ」を理解し始めると、あなたの心は問題を解決する新しい創造的で独創的な方法についての考えに開かれます。