我正在尝试将我的需求写成用户故事。从瀑布世界出发，我对用例更加熟悉。
我喜欢用例的一个原因是与系统的每次交互以及所有备用和异常操作流程都是明确定义的。
UC-01
成功场景：
例外
5a。用户中止，合约没有保存
交替流
1a。用户使用过滤器选择客户
在敏捷方法中将在哪里捕获异常和备用流？
【问题讨论】：
标签： project-management agile scrum agile-project-management
他们不会被这样捕获。
您从错误的角度处理用户故事。来自瀑布，这是一个很常见的误解。
你在这个例子中的故事应该是这样的：
作为用户，我想向客户添加合同，以便 [在此处插入值]
从例子中你可以注意到两点：
我无法完成它，因为我不知道这个故事对客户的价值。这非常重要，因为它推动了对故事的任何谈判。例如，人们不想在价值非常低的故事上花费大量时间。
没有太多细节。这是故意的，因为故事试图捕捉问题或机会，而不是解决方案。 作为用户，我可以通过多种理论方法来实现向客户添加合同的目标。
故事的重点是让用户实现他们的目标。
通常您可以详细说明您当前如何推测故事将在“卡片背面”或 ALM 工具的注释字段中实现，但我正在尝试的重点是要做到的是，故事的实施方式是可以协商的。
您的开发人员希望在迭代期间与您的客户代表互动以讨论/原型设计/尝试各种不同的可能解决方案，以便故事的目标是高效而有效地实现。
一个非常简单但又非常典型的典型示例：如果您忘记了边缘情况、备用流程或异常怎么办？有了故事，这没问题：开发人员发现了它，与产品代表聊天，然后他们制定了处理它的计划。
您可以这样做，因为很明显，处理这些案例是用户故事的一部分。要求不是这样，它规定了解决方案应该是什么，而不是它应该实现什么。
【讨论】：
> Where would the exception and alternate flows be captured in an Agile approach?
用例是功能文档的一种形式。 可以创建此文档
在 Scrum 中，您只需在待办事项列表中有一个功能请求“添加客户”，而没有场景。
【讨论】：
许多敏捷实践并不要求您必须将需求写成带有验收标准的用户故事。所需要的只是一份已订购的需求列表（又名产品待办列表）。在 sprint 计划会议中向团队提供这些要求时，它们应该是最少的信息，但仍然足够清晰，以便团队理解和构建。做得太少修饰和过度分析需求之间有一条细线；这需要时间才能做好。
话虽如此，用户故事之所以常用，是因为它们对参与流程的多方有意义，而其他形式的需求仅限于特定受众；也就是说，您必须教人们如何阅读和理解用例，但不必为用户故事这样做。显然写它是一个不同的问题。
【讨论】：
我喜欢@Sklivvz 和@k3b 的答案。
关于你的例子。
首先：正如 Sklivvz 所写，用户故事定义了问题和目标。我对支线和例外的看法不同。在我看来，这些都是小故事。有自己的优先权。 IE。取消流程的能力可能比某些验证问题的故事更重要。
我的简短回答：为主要目标、次要目标、例外情况和备用流程写一个故事。
积极的副作用：产品负责人（你？）有机会优先考虑这些故事。
【讨论】：
同意以上部分内容并希望添加以下内容（希望对您有用）。
用例并非专门/仅与瀑布相关，它们只是一种可视化系统行为（用例）以及这些行为与其他系统行为之间的关系的方法，以及系统的外部实体（参与者）。
没有理由不能通过用例和用例场景进一步描述用户故事。
记住，仅仅因为你在练习（我猜，但也不受限制）敏捷并不意味着你不能设计东西。只是不要让设计比结果（即产品）更有价值（尽管在复杂的.安全系统中应该是这种情况）。
【讨论】：
当您最初捕捉故事时，它们应该非常简短并专注于好处。
当您与团队讨论解决方案并准备开始实施时，您应该记录更多细节。
我喜欢 Given/When/Then 格式，我会将这个用例重新编写成这个格式（实际目标可能不同，但你仍然会明白主要思想）：
Title:
As a user I want to add contract to customers so that I can track contracts history
Given customers list
When user clicks to Customer
Then he sees Customer Details view
And Add Contract button
[mockup]
Given Customer Details view
When user clicks Add Contract button
Then he see a popup with fields:
Contract Name - field spec: [default value, max lenth, etc]
Contract # - [field spec]
Start Date - [field spec]
End Date - [field spec]
[form mockup]
Given user filled form correctly
When he click Save button
Then he sees confirmation dialog ["Do you really want to add this contract?"]
[注意：我认为这个确认是愚蠢的，不需要]
Given user see a confirmation dialog
When he clicks Yes
Then the contract is saved
And user sees success message "Contract is saved for customer XXX"
Given user see a confirmation dialog
When he clicks No
Then the contract is not saved
And confirmation dialog closes
注意：这个场景很可能是一个单独的用户故事
Given home page
When I click Add Contract link
Then I see Contract form
And "Select customer" drop down field
...
如您所见，您可以很容易地使用 Given/When/Then 格式来描述用户故事。确保捕获用户故事的真正价值非常重要。否则很容易做出一些从业务角度来看非常糟糕的决定。
【讨论】：