Scrum的基本概念其实并不复杂，但是想做好并不容易，大家都知道product backlog的重要性，但是我们如何制定和展现它，如何评定优先级，如何进行初始评估？下面我将介绍和product backlog相关的一些问题。

在Scrum之 流程和术语介绍了流程，这里主要介绍第一个最重要的工件 Product Backlog。它是Scrum的核心，也是一切的起源。它是由Product Owner负责制定的一个按照重要性的级别排序了的故事列表。 

• 什么是Prodcut Backlog
  

backlog英文意思为“积压的工作”。 product backlog是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算。在Scrum中表示可以预知的所有任务，包括未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。Prodcut Backlog永远处于不完整状态，它随着产品及其使用环境的变化而变化，它是动态的，管理层不断对之做出改变，确定产品需求，保证产品适用性、实用性和竞争性。

1. 在列表上层的故事首先被团队完成
2. Product Backlog不是制定一次就完了的，它是动态的，需要持续的被修订，可能会出现故事的增加、删除和修改、合并或者拆分
3. 任何一个Backlog的目标都是：它应该足够短、级别足够高，无特殊情况不需要修改。如果Backlog改变了，那么我认为你应该假设你的 Backlog错了，而不是需求变更了。变更需求通常意味着Backlog太长或者太详细，比如把复杂算法和逻辑也写入了backlog中了，要不就是写 的太含糊不清了，需要花费太多的时间猜测它究竟讲的是什么。

这里有一个别人做的，大家可以参考一下 product sprint示例

Make the Product Backlog DEEP

• Prodcut Backlog有什么用 

产品backlog根据用户价值罗列所有即将在产品中开发的功能，通过简洁的展示需要实现的功能，我们可以对项目进行规模上的估算，确定发布计划和迭代计划。产品backlog可以帮助我们对将要做的事情有个整体的认识，以及可以知道我们现在的状态。如果没有backlog，我们将不知道现在和将来产品做成什么样子，由于对产品目标的不明确，当然也不知道什么时候可以发布产品，或者发布的产品能给客户带来什么价值。

• 谁提供product backlog的需求

产品负责人与客户最近，他最清楚产品应该做什么样子，所以product backlog应该由Product Owner来制定。里面的需求由产品负责人或者客户制定，有时候Team里的需求分析人员可以和产品负责人或客户一起定义需求。制定后，由Scrum master和Team协助产品负责人修订并进行初始评估，里面的需求在sprint计划会议将进行更进一步的讨论。

• 什么时候会修改product backlog

如果一个列表太长或者内容陈旧，product backlog的浪费远大于价值本身，所以我们必须不断的维护产品backlog。产品backlog由产品负责人提供，与Team进行规模估算时，可能会拆分合并或者添加删除故事，初始估计也由Team进行评估提供估计值。产品所有者通常会向开发小组提出自己确定的优先级顺序，而小组也可能会请产品所有者根据他们对主题的评估对这个顺序作出少量调整。

• 怎么写故事

一般按照轻量级的故事来进行描述需求。用户故事是最基本的设计单元，它是从系统用户或者客户的角度出发对功能的一段简要描述。用户故事的形式很自由，没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑 用户故事是比较有益的：“作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到…的结果】以便【业务价值】。”以这样的模作为例子，可以得到一个用户故事说：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而且每个用户故事的开发周期不要太长（1－5天）

我们不需要一开始对所有的故事都进行详细的描述，但计划放在下一个sprint中的故事应该比较清楚。可以按照硝烟一书中的表格来写backlog的故事：

• ID为一个唯一标识，确定后最好固定不变，在其他工作或者文档中想引用故事就使用这个ID来引用
• Name2到10个字，通过简单的描述来说明故事，如果要很多字才能表达这个故事，那很有可能这个故事太大，或者不清楚
• 重要性 这个优先级决定了sprint选择的故事，优先级越高的越早实现
• 初始估算 这个由Team来根据故事描述内容来估算，产品负责人讲解完故事后，Team对不清楚的进行询问，大概了解后进行粗略估算。从估算的角度出发，故事不应该太短，但也不能太过于详细，不需要把具体的规则和算法写进去。
• How do demo 从用户视角，从操作层面进行讲解这个故事如何通过软件来演示，也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写”如何演示“。
• Notes相关信息、解释说明和对其他资料的引用等，一般都非常简短。

有时我还会增加一个分类列来标识出故事的主题，通过主题来从更大视角来查看需求主要内容，后期也可以根据主题的优先级来初始确定故事的优先级。

INVEST in Good Stories, and SMART Tasks

如何沟通故事