ユーザーストーリー定義の「so that」節の目的は何ですか？

ユーザーストーリーは次のような文で定義できます。

As a <type of user> I want <some goal> so that <some reason>

「ユーザーストーリーの公式」のGoogleと最初のリンクはすべて、この公式を提案しています。

私の質問はの目的が何であるか、であるので、その句？マネージャー向けですか？プロジェクト管理者と利害関係者がアイテムの優先順位をよりよく理解できるようにするためにありますか？なぜそこにあるのですか？

注：私はas a <type of user> I want <some goal>数式を使用してきましたが、うまく機能します。より簡潔なこのフォーマットを実装しても、私の作業には問題がありません。

目的は、この機能が存在する理由として、ユーザー/顧客に強固で具体的なビジネス上のメリットを提供するように強制することにより、不要な作業を回避することです。

誰かがクールに聞こえたと思ったから、あるいは他のソフトウェアにそれが備わっているからといって、その機能が追加されることは前例のないことではありません。多くの場合、それらは積極的に有害ではないにしても、少なくとも完全に不要です。

ただし、それらの機能を提案する人々は一般にそれらに説得力のあるビジネス上の理由を提供するのに苦労するので、通常、それらの機能を見つけるのは簡単です。

Popping The Why Stackと呼ばれる手法があります。ここでは、「そう」の部分を取り、「なぜ？」と尋ね、次にその答えを取り、「なぜ？」と尋ねます。再び、再帰的に。「それは私たちにお金を節約できますので、」「なぜ」の、あなたは、好ましくは正確に正確な記述で（どちらか「それは私たちにお金を稼ぐだろうから」に到着したりしていない3〜5の後に（聞かせてのは言う）、場合どのようにそのが発生する予定です）、その機能を実装する価値はありません。

一部の人々は、これが非常に重要であると信じて、実際にストーリーテンプレートの最初に配置します。

のために [...]

として [...]

したい [...]

Thoughtworksの人々による講演の良い例があります。クライアントの1人は、非常に奇妙な方法でフォーマットされた印刷されたレポートを望んでいました。コンサルタントが「なぜ」と尋ねると、そのように入力する方が簡単であると述べました。したがって、レポートのフォーマット機能を実装する代わりに、ネットワーク経由でレポートを転送しました。「そのように」という条項がない場合でも、彼らはこれらの論文を1つの部門で印刷し、他の部門に郵送して再度入力します。

「そう」は目標の理由を提供します。

たとえば、先月の売上高を表示することが目標になる場合があります。それで作業することもできますが、より深い要件に到達できるようにそれらを表示する理由を知る必要がある1つの理由があります。彼らは売上高や見込み客に何をしたいですか？この情報を知ることで、アプリケーションに対する洞察が深まり、顧客が望むことを実行できるようにするユーザーインターフェイスを設計する機会が増えます。

この理由の別の用途は、ストーリーに優先順位を付けることです。2つのストーリーがある場合：

先月の売上高を表示したい。
見込み客の一覧を表示したい。

しかし、それを行うためのリソースしかありません-あなたはどちらをしますか？理由がわからなければ、推測するだけで、適切なタイミングで納品できない可能性があります。お客様は最初にどちらを行うべきかを指示する必要があるため、これはそれほど重要ではありませんが、場合によってはそうではありません。

言われたことに加えて、要件の理由を提供することで、要件の有効性を判断することができます。ユーザーは間違った理由で物事を欲するかもしれません。「そうする」ことで理由が明確になるため、アナリストはこの方法でリクエストが最もよく満たされていることを検証できます。

例：

AIは全従業員のリストから従業員を選択できるようにしたい

BIは、全従業員のリストから従業員を選択できるようにして、5年前に退職した従業員を削除できるようにしたいと考えています。

（B）中規模の組織でも意味がありませんが、ユーザーの要件を検証し、顧客が要件を満たすための別の方法を提案できます。