在 Scrum 中有三个文档是必须要写的，它们是：product backlog、sprint backlog、burn-down chart。
1. product backlog
product backlog 是整个项目的需求概要文档。由 PO 专职负责，一般每周更新一次，在项目的整个生命周期间存续。
用一句简短的、用户熟悉的语言表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事。
用户故事一般用三段论式的方式描述：
As a XX, I want to XX, so that XX.
作为一个XX角色, 我想要XX功能, 以便于实现 XX 商业价值的目的。
PO 根据对客户、对最终用户的商业价值来划分用户故事优先级。
PO 通过和客户进一步调研，以及和团队成员沟通，确定和完善用户故事的验收标准。
用户故事 “3C” 原则
如果能够明确到某个故事，就描述在故事的验收标准中；如果不能明确到某个故事，就单独写个“技术故事”，单独列出来这些非功能需求。
理想的用户故事具有“ INVEST”特点：
（1）独立性 Independent
尽可能避免故事之间存在依赖关系，否则会造成划分优先级的困难，在安排开发顺序时需要考虑故事之间的依赖关系。
（2）可协商性 Negotiable
故事是可协商的，故事是有弹性的，不是必须实现的书面合同或者需求。
（3）对客户有价值 Valuable
确保每个故事对客户有价值的最好方式是让用户编写故事。
（4）可预测性 Estimable
开发者应该能够预测故事的规模，以及编码实现所需要的时间。
（5）短小精悍 Small
一般一个故事在一个迭代周期内是可以实现的。
（6）可测试性 Testable
所编写的故事必须是可测试的，能够定义出验收标准。
用户故事是如何估算的？
用户故事的估算单位是故事点（Story Points），代表了开发用户故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。这可能包括：
3. burn down chart
burn down chart 译为燃尽图，还是很形象的，显示当前 spint 中未完成的任务数目，是展示项目进展的一个指示器。
1. product backlog
product backlog 是整个项目的需求概要文档。由 PO 专职负责，一般每周更新一次，在项目的整个生命周期间存续。
用户故事一般用三段论式的方式描述：
As a XX, I want to XX, so that XX.
作为一个XX角色, 我想要XX功能, 以便于实现 XX 商业价值的目的。
例如：作为一个家庭主妇，我需要一个 30 平米的餐厅，以便于我招待 10 位朋友用餐。
例如：作为系统的合法用户，可以通过录入账号和密码登录到系统中。
例如：作为系统的合法用户，可以通过录入账号和密码登录到系统中。
PO 根据对客户、对最终用户的商业价值来划分用户故事优先级。
PO 通过和客户进一步调研，以及和团队成员沟通，确定和完善用户故事的验收标准。
用户故事 “3C” 原则
- Card 可以写在卡片上
- Conversation 用于对话
- Confirmation 及时确认
至此，product backlog => 需求 + 优先级 => 用户故事 + 优先级 + 验收标准 => 用户角色 + 功能 + 目的 + 优先级 + 验收标准
前面说的都是功能需求，对于非功能需求怎么办？如果能够明确到某个故事，就描述在故事的验收标准中；如果不能明确到某个故事，就单独写个“技术故事”，单独列出来这些非功能需求。
理想的用户故事具有“ INVEST”特点：
（1）独立性 Independent
尽可能避免故事之间存在依赖关系，否则会造成划分优先级的困难，在安排开发顺序时需要考虑故事之间的依赖关系。
（2）可协商性 Negotiable
故事是可协商的，故事是有弹性的，不是必须实现的书面合同或者需求。
（3）对客户有价值 Valuable
确保每个故事对客户有价值的最好方式是让用户编写故事。
（4）可预测性 Estimable
开发者应该能够预测故事的规模，以及编码实现所需要的时间。
（5）短小精悍 Small
一般一个故事在一个迭代周期内是可以实现的。
（6）可测试性 Testable
所编写的故事必须是可测试的，能够定义出验收标准。
用户故事是如何估算的？
用户故事的估算单位是故事点（Story Points），代表了开发用户故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。这可能包括：
- 工作的数量
- 工作的复杂度
- 工作中存在的任何风险或不确定性
故事点是一个相对值，一般用 Fibonacci 数列来表示：0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89。虽然可以分为 12 个等级，但一般只采用0、1、2、3、5、8、13 这 7 个等级。如果在预估中发现超过 13 的，一般把任务分割为两部分。
等待 PO 基于商业价值挑选完毕某次交付中应该包含的用户故事后，接下来，Team 就可以挑选在某次迭代中要实现的用户故事了。
2. sprint backlog
sprint backlog 是在 sprint planning meeting 上讨论确认的任务列表。每个任务以小时为单位，一般没有超过 16 小时的任务。
sprint backlog 由 Team 专职负责，每天更新一次，在 spring 生命周期间存续。
等待 PO 基于商业价值挑选完毕某次交付中应该包含的用户故事后，接下来，Team 就可以挑选在某次迭代中要实现的用户故事了。
2. sprint backlog
sprint backlog 是在 sprint planning meeting 上讨论确认的任务列表。每个任务以小时为单位，一般没有超过 16 小时的任务。
sprint backlog 由 Team 专职负责，每天更新一次，在 spring 生命周期间存续。
每个任务完成的标志是什么？
（1）Team 成员检测：所有的单元测试通过。
（2）PO 检测：所有的功能测试通过。
burn down chart 译为燃尽图，还是很形象的，显示当前 spint 中未完成的任务数目，是展示项目进展的一个指示器。
每天开完 15 分钟站立会议后，由 SM 负责更新燃尽图。
横坐标为工作日期，纵坐标估计剩余的工作量，每个点代表了在那一天估计剩余的工作量。通过折线依次连接起所有的点形成为估计剩余工作量的趋势线。另外还有一条控制线，为最初的估计工作量到结束日期的连线，一般用不同的颜色画上边的两根线。
对此图的研判规则如下：
（1）如果趋势线在控制线以下，说明进展顺利，有比较大的概率按期或提前完工。
（2）如果趋势线在控制线以上，说明有比较大的概率延期，此时需要关注进度了。
注意，趋势线并非一直下行，也有可能上行，即发生了错误的估计或遗漏的任务时。
