Product Backlog源自于Scrum方法，是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。那么，如何制定Product Backlog呢？

Product backlog是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕Product backlog来进行。在制定Product backlog的过程中会遇到很多问题，接下来，我们将结合Worktile敏捷开发实例，带大家一起学习如何制定Product backlog 。

一、Product backlog和用户故事

Product backlog是Scrum的核心，也是一切的起源。它是由Product Owner负责制定的一个按照重要性的级别排序的用户故事列表。

规模较小的用户故事可以直接加入Product backlog；规模较大的用户故事要先拆分，再加入Product backlog进行迭代。

用户故事是一句简短的、采用用户熟悉的术语表达的需求，是Product owner讲给开发人员的故事，含有一定业务价值的端到端交付。

用户故事是描述对用户有价值的功能，一个好的用户故事应该包括角色、功能和商业价值三个要素。

1. 角色：到底是谁要使用这个功能，这个功能是为谁而设计的？
2. 功能：这个功能是怎样的，要达到什么程度？
3. 商业价值：为什么要这个功能，这个功能最后能带来什么有益的商业价值，对用户来说有什么意义？

一般我们在描述一个用户故事的时候会按照以下格式：

作为一个<角色>, 我想要<功能>, 以便于<商业价值>。

比如：作为一个“项目经理”，我想要“有快捷方法把所有项目生成甘特图”，以便于“项目管理和查看所有项目进度。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。在Worktile中，我们用一个任务类型为“敏捷需求”的任务代表一个用户需求。

二、如何编写Product backlog或用户故事

Product backlog一般由Product owner编写，再确定优先级，最后在Sprint plan meeting上和开发团队确认。但有时研发团队也会写，比如：作为研发人员，我需要写一个操作缓存的模块，这就是研发initial的backlog。

用户故事看似简单，但是其实是很难写。比如：作为会议管理员，可以查看所有用户的提问，以便了解哪些用户发表的评论。看上去这种价值描述不错，但是如果系统只是为了查看的话，会议管理员为什么要查看？如果评论很多，他如何查看？

所以用户故事的价值描述其实是给需求分析做了一些价值挖掘的要求，团队要去挖掘角色做这一动作的价值，并为角色挖掘出必要且合理的理由。

用户故事具备以下六个特征：

1. 独立性（Independent）：要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常可以通过两种方法来减少依赖性：

1. 将相互依赖的故事合并成一个大的、独立的故事；
2. 用一个不同的方式去分割故事。

2. 可讨论性（Negotiable）：故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

3. 对用户或客户有价值的（Valuable）：用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个合同，而且可以进行协商的时候，他们将非常乐意写下故事。

4. 可估算的（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：

①开发人员缺少领域知识；

②开发人员缺少技术知识；

③故事太大了。

5. 小的（Small）： 一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

6. 可测试的（Testable）：故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。

在很多项目中，Product owner只是从一个角度编写Product backlog，这样往往容易忽略很多需求。所以在编写用户故事前要识别用户角色和虚拟人物(Personal)，从不同角度编写Product backlog 。

以下是招聘网站可能出现的用户角色列表：

三、如何确定Sprint backlog的优先级

编写完Product backlog后，Product Owner需要对需求进行优先级的评定，根据优先级从高到低依次作为Sprintbacklog。评定标准由Product Owner定。

对于一些无法估算时间成本的backlog，需要细化到一个能估算的backlog为止。

例如，此次的backlog是A功能，但要做A功能的时间无法估算，拆分A功能发现要做A需要先做B功能，可要做B功能的时间也无法估算，再拆分B功能发现要先做C功能，而C功能可以估算。这时的Backlog优先级就是C→B→A。

需要注意的是，Sprintbacklog在项目进展过程中是会发生变化的，只有Product owner有权来修改优先级。

四、Worktile是如何管理Product backlog的

Worktile支持自定义任务类型，这表示客户可以根据自己的需求，灵活配置任务的状态／属性信息，以及任务的工作流以及关联关系等。Worktile中用一系列的标签来区分用户故事的信息，需求来源对应角色，任务名称对应功能，还可以自定义规模、优先级等。

Worktile对Product backlog的管理，是按照以下几个步骤进行的：

1. 通过收集社区、帮助中心、后台的客户反馈，由客户成功整理出自客户／产品／售后等渠道的用户故事，由产品负责人细化为需求；
2. 在Worktile中建立项目和需求任务；
3. Pruduct owner整理需求池；
4. 安排研发优先级；
5. 在Sprint plan meeting上Scrum团队沟通，给开发团队分配任务。

当开发团队完成了Product backlog并不是就真正的结束了，还需要验收，或者叫用户故事的测试要点，验收标准由Product owner自己决定或是在Sprint Review Meeting和开发团队一起决定，每个团队的验收标准都不一样，有些团队以需求完成作为验收标准，有些团队以需求通过测试为验收标准，但总体的验收标准遵循DoD（Definition of Done）原则。

综上，一个完整的Product backlog = 用户故事+ 优先级 + 验收标准。

#专栏作家#

袁林，人人都是产品经理专栏作家。分享SaaS运营和企业管理／协作／办公的相关知识

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议