Backlog编写指南

产品Backlog实际上就是用户需求，就是一个需求、故事或特性组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。

 

Backlog也叫用户故事。

 

Backlogd的写法不拘一格（可参考《硝烟中的scrum.pdf》中的模式，或《移山之道》中的模式），但要满足以下的原则：

1.便于理解。

2.完整独立。

3.可以验证。

 

找了个比较正规的解释，好的Backlog要满足INVEST准则：

I-Independent

N-Negotiable

V-Valuable

E-Estimable

S-Small

T-Testable

 

如果客户提个几个需求可以整到一个Backlog中的，可以整到一起。如果是一些具体的技术要求（如要将某个表、某个字段设计成怎样怎样.......），也可以整成Backlog。虽然一般来说，Backlog主要是讲业务层面的，而不是实现层面的，但现实情况如此的话，就变通一下吧。

 

Backlog通常由产品负责人（或叫产品经理？）来编写，但由于实际的情况，他可能有些情况也没考虑到，通过交流，团队成员也会提出些新的Backlog或对已有的Backlog进行补充。在我们的实际情况中，可以让大家协助编写Backlog。但要有人最终负责对其优先级进行设定。这里的优先级一般是根据客户的要求及项目组内部的判断而来的（如某个任务不先完成，后面的事就没法做，但确实是这样吗？那就需要判断了）。

 

如何把握Backlog的粒度？一个原则是一个Backlog项，至少要在一个迭代（Sprint）内能完成。如果一开始写粗点了也没关系，在进行Sprint计划会议时发现太粗了，一个迭代完成不了，可以将它拆分成几个较小的。

 

另外，还需要定义完成标准，是代码提交了就算完成了？还是通过测试算完成了？还是部署到客户那算完成了？

 

举个例子：

Grape项目中的#2148：教师或学生登录手机App。【作为 <教师或学生>，我要 <登陆教务手机APP>，以使 <我能正常查看课表或者查分>】

   1.教师和学生登录手机App的流程是否是一样的？如果不是一样的那么这就不是一个独立的Backlog。

   2.登录的具体过程如何呢？还有些什么关键点呢？是否要密码？密码是否区分大小写？用户名是否区分大小写？是否可以记录用户名？是否可以记录密码下次自动登录？密码传输过程中是否加密？觉得写Backlog时可以考虑的多些。但这些不一定都做，或者可以先做优先级高的。

   3.写的不细，也就没法验证了。

 

 

总的来说，一个Backlog，就是描述了一个完整的，对用户有价值的需求。如果把这个需求实现了，马上就能给客户演示，并获得反馈。

 

另外，一开始写Backlog总是痛苦的，但有了积累后，再有类似项目，只需要把以前的Backlog拿来修修改改就可以了。例如所有信息系统中都有的用户登录、权限管理等，这些是可以形成公用的Backlog的。复用存在于各个层面。

我们的规则： 1.情景点使用天为单位。 2.任务耗时使用小时为单位。