用户故事的生命周期是怎样？

　　敏捷方法使用用户故事来捕获系统或软件应该支持的功能，用户故事是什么？如何编写用户故事的详细参考信息。

　　项目开始时，用户故事在故事写作研讨会中被酝酿和开发 - 一个头脑风暴会议，敏捷团队（通常包括客户，产品经理，开发人员，测试等人员组合）想出了尽可能多的用户故事，每个故事都是第一次确定大小和优先级。这个优先级列表创建产品待办事项（发行版计划安排）。

　　在研讨会期间，团队选择迭代周期（通常在1到4周之间）以及他们能够完成用户故事的速率（调用速度），这两者在确定如何安排用户故事的过程中非常重要。

　　在迭代计划过程中，产品/发布积压中包含的用户故事被分段为迭代或冲刺。第一个sprint的用户故事构成了sprint积压。

　　第一次迭代准备启动后，敏捷团队成员之间的每个用户故事都会开始对话，用户故事以对话的详细信息进行更新，以验收测试的形式捕获。

　　用户故事可以根据需要随时更新，直到迭代编码完成。

　　如果由于某些无法预料的原因而无法在迭代期间完成用户故事，则会将其返回到产品待办事项并重新安排进行另一次迭代。

　　许多敏捷方法要求在编写和实现用户故事后将其丢弃。但是，敏捷方法具有灵活性和适应性，因此确定是否保存和维护用户故事通常因公司而异。