一、用户故事描述了对系统或软件的用户或者购买者都有价值的功能。

由以下三部分组成：
1.一份故事的书面描述，用于做计划和提示
2.有关故事的对话，用于充实故事的细节（客户团队与开发之间的对话，有助于回溯精确度）优于需求文档
3.传递和记录故事细节的测试，用来判断故事是否完成 （客户传达他对故事的期望和假设）

例如一个招聘网站，可以描述成2个故事，这两个故事可以很容易地覆盖招聘网站大部分功能，可以称为史诗。史诗可以拆分成更多较小的故事。直到有了一个可以包括所有最终细节的故事，才不继续拆分故事。可以将细节注释在故事卡片上。
1.用户可以搜索工作
1.1用户可以通过诸如工作地点、薪资范围、职位名称、公司名称和工作内容等字段来搜索工作
1.2用户可以查看搜索到的想匹配的每一个工作的信息（不用继续拆分成：用户可以查看工作描述等故事）
1.3 用户可以查看已经发布的工作所属公司的详细信息
2.公司可以发布空缺职位

写完故事后，可以将用户期望以验收测试的形式记录下来。

比如上诉的例子：
用空白的工作描述来尝试。
用真实的较长的工作描述来尝试
用缺少薪资来尝试
等

完成故事集之后，应对故事集进行优先级排序。进行优先级排序要考虑如下因素：

1.这一特性对大多数用户或者客户是否具有吸引力
2.对于少数重要用户或者客户来说，这一特性是否具有吸引力
3.故事与其他故事之间的内聚关系。本身是低优先级的，但作为其他故事的补充，就可能具有高优先级
4.注意技术风险或者是否与其他故事互补关系
5.必须考虑成本。（故事的成本由开发人员估算，每个故事都有一个故事的点数估算。表明这个故事相较于其他故事的规模大小和复杂性。
完成优先级的排序，将故事分成不同批次，每次批次代表一个迭代。 选择1-4周的迭代长度，根据迭代长度，开发估算他们在每次迭代中能完成多少工作（称为速率）。根据速率来确定这次迭代开发的故事。每次迭代前都可以修正计划。

一个好的故事的特征

• 独立的 （尽量避免故事相互依赖，当故事出现高度相互依赖，则可以通过合并故事或换一种方式拆分故事的方式避免）
• 可协商的（故事不应该包含太多的注释，会造成错误关注不应该关注的细节；可以将太多的细节变成验收测试）
• 对用户或客户（购买软件的人）有价值的（有一些可能只对客户有需求，但用户（使用者）并不关心）
• 可估算的 （无法估算的常见原因：1.开发人员缺少领域知识 （应与客户进行讨论）2.开发人员缺少技术知识3.故事太大了）
• 小的 （史诗分为复合故事、复杂故事应拆分更更多较小的故事；复杂故事不易拆分，若因不确定因素变得复杂，可拆分成1.研究性的2.开发新功能的；例如故事“一个公司可以用信用卡支付职位招聘"可拆分成：1.在网上研究信用卡处理过程2.用户可以用信用卡支付）
• 可测试的

可协商的例子： 细节过多的故事卡.jpg
修正后的故事卡正面和侧面.jpg