健康的Product Backlog就像一个健康的人那样：整洁有序、组织合理、公开透明。
一个按照优先级顺序排好的敏捷Backlog不仅能够简化发版和迭代计划，还能够对团队计划去做的所有工作进行细致规划——包括客户根本不会关注的内部工作。尤其是当利益相关者和其他团队对团队提出额外的工作需求时，Backlog能够帮助他们设定期望指标，同时还能够使工程时间具备价值，产出实际可交付的成果。
什么是Product Backlog？
Product Backlog是开发团队根据路线图及需求制定的按优先级排列的列表。其中，最重要的项目显示在Product Backlog的顶部，确保团队知道这就是要先交付的成果。因此，开发团队不是按照Product Owner规定的节奏开展工作，Product Owner也不会是开发团队完成工作的驱动者。相反，开发团队根据Product Backlog中的顺序推进工作，通过看板的持续改善或scrum的迭代来完成这些项目。
专家提示：将所有工作内容存储在同一个任务跟踪器中——不要使用多个系统来管理bug、需求和研发工作项。如果是要求开发团队完成的工作，就请将其保存在单个列表中。
以两个“R”为出发点
团队的路线图和需求为Product Backlog奠定了基础。路线图计划可以拆分为几个史诗（epic），每个史诗（epic）都包含几个需求和用户故事。 让我们来看看一个名为Teams in Space的虚构产品的路线图。
由于Teams in Space网站是路线图中的第一个任务，我们希望将这一任务分解为下面三个不同的开发史诗（epic）（这里以绿色、蓝色和蓝绿色显示）和每个史诗（epic）中各自不同的用户故事。
然后，Product Owner将每个用户故事的需求，整合到开发团队的单个列表中。Product Owner可以先提供单个完整的史诗（epic）（左图）。或者，如果预订折扣航班的测试对这个系统来说更为重要时，就需要来自几个史诗的用户故事（右图）。 下面是两个例子：
哪些因素可能会影响Product Owner的优先级排序？
- 客户优先权
- 紧急反馈
- 相对实施难度
- 工作项之间的关联关系（如：如果先做完A，B会更容易）
虽然确定Product Backlog的优先级顺序是Product Owner的任务，但绝对不应该在封闭的情况下完成。实际上Product Owner会通过收集来自客户、设计人员和开发团队的意见和反馈，来优化每个人的工作量和所需交付的产品。
确保 Backlog处于健康状态
Product Backlog一旦创建，非常重要的一点就是要通过定期维护来确保它能够与开发项目的整体节奏保持一致。Product Owner在每次迭代规划会议前，都应该评审backlog，以确保优先级顺序正确无误，且上一次迭代的反馈已经被整合到本次迭代中。敏捷圈通常将Product Backlog的定期审查称为“Backlog修饰”。 如果Product Backlog的规模变大，Product Owner就需要按照短期和长期项目，将backlog进行分组。贴标签前，短期项目需要完善细节。这需要与设计和研发一起协作制定完整的用户故事、估算开发时间。较长期的项目不需要特别清晰具体，但最好能让开发团队做一个粗略的估计来判断项目的优先级。这里的关键词是“粗略”——也就是说团队完全理解并开始着手做长期项目后，所有的估算都有可能发生改变。 Backlog作为连接Product Owner和开发团队之间的桥梁。如果是由于客户反馈、精炼估算和新需求出现等原因，Product Owner可以随时重新变更backlog的优先级。但是，一旦进入开发阶段，尽量将更改的机率降到最低，因为这样会打乱开发团队的节奏并影响工作的聚焦点、流程和士气。
专家提示：一旦backlog超出了团队的长期能力，可以尝试关闭团队几乎无法达成的任务。在团队的任务跟踪器中，用特别的表述来给这些任务做标记，如“超出范围”等，以便用于稍后研究。
需要注意的非常规现象:
- Product Owner在项目一开始就对backlog进行了优先级排序，并且在开发人员和利益相关者提供反馈意见时也没有对其进行调整。
- 开发团队将backlog中的事项限制为面向客户的项目。
- Backlog存储在本地，不经常共享，导致感兴趣的各方无法获取更新后的内容。
Product Backlog如何让团队保持敏捷？
经验丰富的Product Owner会严格修改其项目的Product Backlog，使其成为可靠且可共享的工作大纲。 Backlog鼓励能够让项目变得更健康的讨论和决策——因为并不是每项任务都可以排在第一位。 利益相关者可以质疑既定优先级，这是一个很好的做法。围绕优先事项进行讨论能够确保每个人的优先事项保持一致。这些讨论可以促进团队优先级一致性的文化，确保项目中的每个成员都有优先级一致的思维。 Product Backlog同时也是迭代规划的基础。所有工作项都应包含在backlog中：用户故事、bug、设计变更、技术债、用户提出的需求、回顾中的操作项等。这样做可以确保每个迭代的每个人的工作项都包含在整个讨论中。然后，在完全知晓需要完成的所有事项的情况下，团队成员可以在迭代开始前与Product Owner一起权衡此次迭代的工作项。
专家提示：Product Owner决定了backlog中工作项的优先级，而开发团队则通过backlog来决定团队开发速度。而对于希望将工作“推”给团队的新Product Owner而言，这可能是一种难以平衡的关系。
Worktile 官网：worktile.com
内容整理：Worktile
文章首发于「Worktile官方博客」，转载请注明出处。
