用户故事可以用如下语句来定义：
As a <type of user> I want <some goal> so that <some reason>
只是Google的“用户故事公式”和第一个链接都提出了此公式。
我的问题是，该条款的目的是什么？经理那里吗？是否在那里使项目经理和利益相关者可以更好地了解项目的优先级？为什么在那儿？
注意：我已经处理过as a <type of user> I want <some goal>公式，并且效果很好。通过采用这种更简短的格式，我在工作中没有发现任何问题。
Answers:
目的是通过迫使用户/客户提供可靠的，有形的业务利益（作为存在此功能的原因）来避免不必要的工作。
并不是因为有人认为它们听起来很酷，或者是因为其他软件拥有它，所以我们也必须拥有它，所以才增加了这些功能。多数情况下，即使它们不是有害的，它们也至少是完全不必要的。
但是，通常很容易发现这些功能，因为提出这些功能的人通常很难为它们提供令人信服的商业理由。
有一种名为Popping The Why Stack的技术，您在其中选择“ so that”部分，然后询问“ Why？”，然后您得到该答案，然后询问“ Why？”。再次，递归地。如果经过（比方说）三至五个“为什么” S，你有没有在任“因为它会让我们的钱”到达或“因为它可以节省我们的钱”（最好用的完全是一个精确的描述怎么说即将发生），那么该功能就不值得实现。
有些人认为这是非常重要的，他们居然把它首先在故事模板：
为了 [...]
作为一个 [...]
我想要 [...]
一些Thoughtworks员工的演讲中有一个很好的例子：他们的一位客户希望以一种非常特殊的方式格式化打印的报告。当顾问问“为什么”时，他们说这样更易于键入。因此，他们没有实现报告格式设置功能，而是通过网络传输了报告。如果没有“ so that”子句，他们仍然会在一个部门中打印出这些文件，然后将其邮寄给另一个部门，然后再输入。
“如此”提供了实现目标的理由。
例如，目标可能是显示上个月的销售数据。您可以使用它，但是您需要知道为什么要显示它们的一个原因，这样您才能满足更深入的要求。他们想与销售数字或前景做什么？了解这些信息将使您对应用程序有更多的了解，并有更多的机会设计使客户能够执行他们想要的操作的用户界面。
原因的另一个用途是优先处理故事。如果您有两个故事：
我想显示上个月的销售数字。
我想显示一个潜在客户列表。
但只有资源来做一件-您要做哪一件？没有原因，您只是在猜测，您可能无法及时交付正确的产品。尽管这不太重要，因为客户应该告诉您先做什么，但有时情况并非如此。
除了已经说过的话，提供需求的原因还可以使您判断需求的有效性。用户可能出于错误的原因想要东西。拥有“这样”可以澄清原因，从而使分析人员可以验证以这种方式最好地满足了请求。
例：
AI希望能够从所有公司员工的列表中选择员工
BI希望能够从公司所有员工的列表中选择员工，以便我可以删除5年前离开公司的员工。
（B）即使在中等组织中也没有意义，但是您可以验证用户需求并为客户提出另一种满足需求的方法。