我在工作中遇到了一个问题，我们刚开始使用scrum作为开发团队。我对我们提供的用户故事有些麻烦，因为它们似乎不符合我对用户故事的解释。
以下是我们为此sprint提供的用户故事的实际示例：
作为网站用户，我希望有一个注册页面，以便我可以注册并提供我的详细信息。
作为商家用户，我希望在注册表单上进行验证，以便我提供正确的信息。 （这与表单验证有关）
作为商家用户，我希望在注册时获得支持，以便回答有关所需详细信息的任何问题。 （这与表单上的工具提示有关）
我脑海中的第一个是用户故事。第二个似乎是第一个用户故事的传统要求，我认为它们应该是第一个用户故事的接受标准。
我遇到的另一个困惑是我们最后一次冲刺：
作为一名用户，我希望能够登录该网站。
作为一名用户，我希望能够使用用户名登录该网站。
产品负责人说这是两个不同的用户故事，需要单独测试。
我的问题是，在为后两个创建测试用例和验收标准时，它很难，因为它们非常具体，与第一个用户故事有关。看起来我们只是在卡上提出传统要求并将其称为其他东西。我主要想知道我是否错了这个/为什么？
在我看来，我们目前只是让用户创建他们想要的任何用户故事，而不是帮助他们将他们从需求过滤到适当的用户故事。我被告知我们需要将它们全部分开报告，以便我们可以记录用户请求的所有内容。
答案 0 :(得分：11)
用户故事关注客户价值。 ......正在进行的实际工作是充实的 通过协作围绕用户故事作为系统 发展进步。 ...为了限制范围，用户故事有 协同制定的验收标准，定义何时 用户故事符合利益相关者的期望。通常是测试用例 开发为代码（具有测试驱动开发）或记录为 代码开发。
[强调我的。]
作为用户，我希望能够登录该网站。
作为用户，我希望能够使用用户名登录网站。
由于既没有提供任何客户价值，也没有用户故事。
您使用应用程序软件来管理信息，做出决策并（最终）采取行动。如果用户故事没有提供关于采取什么信息，决策或行动的暗示，那么就没有客户价值，这只是技术文件夹 - 客户必须忍受的实施细节应用程序的有趣部分。
登录，具体而言，客户价值为零。这是IT在客户之间建立的障碍，以及他们做出决策和采取行动所需的有价值信息。这是一种安全机制，大多数人实际上并不喜欢安全性。 IT部门对客户施加安全保护。最受欢迎的密码（IIRC）是“aaaaaaaa”。为什么？客户不喜欢安全。
详细的，微观的登录用户故事可能是未能看到客户真正价值的症状。
在我看来，我们目前只是让用户创建他们想要的任何用户故事
好。
我被告知我们需要将它们全部分开报告，以便我们可以记录用户请求的所有内容。
真的不错。
问题在于将“用户碰巧说的废话”与“我们可以构建的有意义的东西”分开。允许用户说出他们想说的任何废话是非常非常重要的。让他们漫步是一件好事。
定期（在每个sprint之前），您将优先考虑用户所说的一些事情（1）您可能在sprint期间构建，以及（2）创建您可能创建的最重要和最具戏剧性的用户价值。有些故事会被忽略。有些将是低优先级。有些将合并，有些将被拆分。用户说的一些事情将是矛盾的。有些人将是彻头彻尾的谎言。有些将是不完整的。都很好。这只是用户碰巧说的垃圾。不是从神的口中直接指向你的神圣指示。
这套经过修改的用户故事推动了冲刺。现在，您开始与用户协作以获取详细信息，编写测试用例，定义接受等等。
当你正在向交付冲刺时，用户可以继续说废话，这些废话将附加到未实现的用户故事的积压中。允许用户说出他们想说的任何废话是非常非常重要的。让他们漫步是一件好事。