产品Backlog

首先在Mike Cohn《Succeeding with Agile》中提到，关于产品Backlog的DEEP原则

• 详略得当（Detailed Appropriately）

接下来的Sprint中要完成的用户故事，需要足够的详细。而不着急开发的，则不必太详细。

• 做过估算的（Estimated）

产品Backlog中靠后（下）（优先级低）的事项没有充分理解（也不必），因此其估算也不如靠前（上）（优先级高）的用户故事估算精确。

• 涌现的（Emergent）

产品Backlog不是静止的。随着了解的深入，产品Backlog中的用户故事会增加、减少或重新排优先级。

• 排列优先级的（Prioritized）

产品Backlog应该根据由上至下按照条目的价值从高到低排序。团队应从中根据优先级进行开发，从而使正在开发的产品或系统价值实现最大化。

什么是用户故事？

用户故事是一个方便的格式用来表达多种类型的产品Backlog条目，特别是特性的期望业务价值。制作用户故事的方式是让业务人员与技术人员都能理解需求。用户故事结构很简单，并且为会话提供一个很好的占位符。此外，用户故事可以在不同程度的粒度上编写以及很容易逐步细化。

3C

下面说说PB里面的形式之一，user story（Jeffries 2001），最早是Ron Jeffries在2001年提出user story需要满足3C原则： Card(卡片), Conversation(会话), Confirmation(确认).

1. 卡片：

我们并不打算用卡片去捕获组成需求的所有信息。实际上，我们故意使用有限地方的小卡片来促进用户故事简洁。卡片上应该只有几句话来捕获需求的精髓或目的。它也用作占位符以便在利益相关人、产品负责人及开发团队之间进行更细化地讨论。

2. 会话：

需求的细节是在开发团队、产品负责人及利益相关人之间的会话中暴露和沟通的。用户故事仅仅为有这个会话的一个承诺。

3. 确认：

用户故事还要包含满意条件形式的确认信息。这些是澄清期望行为的验收标准。开发团队用验收标准来更好地理解构建和测试什么，产品负责人用它来确认实现的用户故事达到他的满意。

INVEST

后来Bill Wake在2003年又总结了关于user story的INVEST原则：Independent(独立的), Negotiable(可协商的), Valuable(有价值的), Estimable(可估算的), Sized Appropriately or Small(大小合适的), Testable(可测试的).

1. 独立的：

当采用_独立_标准时，目的不是消除所有的依赖，而是用最少依赖的方式编写故事。

2. 可协商的：

故事不是预先的需求文档形式的书面合同。相反，故事是会话的占位符，在会话中细节是可协商的。

3. 有价值的：

故事需要对客户、用户或者两者都是_有价值的_。客户（或者选择者）选择并支付产品。用户实际使用产品。如果故事对他们没有价值，这个故事不应纳入产品Backlog。

_有价值的_标准的关键是从产品负责人的角度看在Backlog中所有的故事必须是有价值的（值得投资），它代表客户与用户的角度。不是所有的故事都是独立的，也不是所有的故事是完全可协商的，但所有的故事必须是有价值的。

4. 可估算的：

故事应该对设计、构建及测试它的团队可估计的。估算说明了故事的大小，因此也就说明了工作量和成本。（更大的故事比开发小的故事需要更多的努力与成本、更多的钱）。

5. 大小合适的：

当我们计划开始做故事的时候它们应该是_大小合适的_。在Spint中要工作的故事应该是_足够小的_。如果我们执行一个几周时间的Sprint，我们想要工作的几个故事，每个都是几天大小的。如果我们有一个两周的Sprint，我们不想有一个两周大小的故事，因为完不成这个故事的风险太高了。

6. 可测试的：

_可测试_的故事指的是一种非此即彼的方式—相关联的测试要么通过，要么失败。可测试的意味着有和故事关联的良好的验收标准（与满意条件有关），即我早先讨论过的故事“确认”的方面。

补充一个“用户故事的ODDE与5C”