开发团队按照节奏从 Product backlog 中主动领取工作，可以更加有动力地进行持续迭代和持续交付。在这里向大家介绍如何构建以及维护 Product backlog ，以及如何用好这一实践让团队更加敏捷。
一、Product backlog 具备什么特点？
Product backlog 是开发团队的工作的优先级列表，一般来自产品规划路线图和需求。Product backlog 需要有优先级排序，显示最重要的工作事项是什么，告知团队首先要交付什么。因此开发团队不用被动地根据产品负责人的安排工作，产品负责人也无需不间断地将工作推给开发团队。相反，开发团队按照节奏从 Product backlog 中主动领取工作，可以更加有动力地进行持续迭代和持续交付。
Tips：尽量不要在多个平台记录产品需求、缺陷和其他工作项, 将所有内容统一记录在一个团队都能看到的列表当中，比研发管理工具 PingCode。）
二、如何搭建 Product backlog
产品路线图和产品需求是构成 Product backlog 的基础，比如路线图计划分为几个史诗，每个史诗都有哪些特性和用户故事？
在实际开发工作中, 产品负责人需要将每个用户故事规划到团队的 Product backlog 中。产品负责人可以选择先完成一个特性下的所有用户故事交付, 也可以出于需要选择多个特性下的用户故事交付。
这里涉及到产品需求优先级的影响因素 :
- 来自重要客户的需求
- 需求的紧急程度
- 需求实现难度
- 工作项之间的关联度（例如，工作项A完成后，工作项B完成会更快）
Product owner（产品负责人）需要对产品需求优先级进行排序，合格的产品负责人会去收集各方的信息，比如客户、设计师以及开发团队中收集意见和反馈等，从而综合考虑产品交付的优先级。
三、如何对 Product backlog 进行维护？
在建立 Product backlog 后，定期跟踪和更新维护进度是很重要的。产品负责人应该在每次迭代计划会议之前检查待办列表中的积压，并将上次迭代的反馈也添加进去，以确保需求的优先级正确。
如果积压工作量比较大，产品负责人需要将积压工作项分为近期项目和长期项目。近期项目需要分解为一个个已经具备完整需求描述的用户故事，并完成了工作量估算。长期项目的需求允许一定程度的模糊，但最好先从开发团队获得大致的估算以确定优先级。需要注意的是“大致估算”，而不是准确估算，因为一旦团队准备执行这些需求，工作量估算就需要重新进行。
需要注意的是：待办列表中的需求可能由于客户反馈、估算量和新的规则标准等因素发生改变或新增，这时候产品负责人可以随时调整积压工作的优先级。但是，一旦工作进入到开发中，需求的变更应该保持在最低限度，因为大幅度的变更会扰乱开发团队工作的节奏、流程和状态，甚至导致本次迭代的失败。
Tips：一旦积压工作超出了团队的长期能力，就可以关闭团队永远无法解决的问题。在团队的问题跟踪器中使用特定解决方案（例如“超出范围”）标记这些问题，以供以后研究。
维护 Product backlog 过程中的一些常见的坑:
- 产品负责人在项目开始时没有综合开发团队和利益相关者的反馈来考虑需求优先级
- 团队的计划工作经常随客户的一切需求而变
- 需求文档没有在线共享，阻碍团队同步获得更新信息
四、如何通过 Product backlog 让团队保持敏捷
出色的产品负责人会严格整理 Product backlog ，让开发项目有一个可执行和可共享的工作计划/产品路线。
产品的积压工作在一定程度上会促使敏捷团队主动去讨论产品优先级的最优方案, 从而促进产品更好发展——毕竟不是所有工作都可以放在首位紧急处理的。
利益相关者对现有的需求的优先级提出质疑是很常见的现象，虽然这会让产品负责人难以抉择。但这其实也帮助了敏捷团队去讨论到底需求优先级该怎么排序，这一方面让团队每位成员增强了对优先级的了解， 另一方面也促进了团队文化的培养。
另外, Product backlog 也是迭代计划的基础，所有类型的工作都应该在 Product backlog 中呈现，包括用户故事、缺陷、设计需求、技术债务、客户需求等等，这确保每个人的工作都会在迭代会议中经过大家讨论，合理预估工作量，并达成一致。
以上就是关于如何建立并维护 Product backlog 的全部内容，希望对你有所帮助。
