用户故事是从用户的角度来描述产品需求，包括功能性需求和非功能性需求。一般而言，用户故事都有若干项，那么到底哪几项要先实现，哪几项可以后实现呢？这就取决于用户故事的优先级。市场价值越高的用户故事，其优先级越高；反之越低。除此之外，用户故事还应当有最后完成时间。因此，可以用用户故事、优先级和最后完成时间来描述Product Backlog：
Product Backlog＝用户故事＋优先级＋最后完成时间
此外，还可以用用户角色、用户活动、商业价值、优先级和最后完成时间来描述Product Backlog：
Product Backlog＝用户角色＋用户活动＋商业价值＋优先级＋最后完成时间
譬如，某音乐播放器的Product Backlog需求列表如表3-6所示，用户故事包括用户角色、用户活动以及商业价值，除此之外，Product Backlog需求列表还包括优先级、最后完成时间。Product Backlog每项的状态（Status）和备注（Notes）不是必须项。
表3-6 Product Backlog描述
续表
Product Backlog是一个具有优先级和最后完成时间（最后期限）的需求列表，包括未细化的产品功能要求、性能指标、缺陷、软件版本更新等。这些需求项可能不是完整的，可能随时会发生变更，尤其可能随市场、政策、产品使用环境或者产品依赖条件的变化而变化。
那么，什么样的Product Backlog才是合格的需求列表呢？
（1）足够短。
如果某个Product Backlog项太长或者太详细，把技术方案和实现算法都写进去了，那就不叫“用户故事”了，而变成实现方案了。
（2）级别足够高。(www.xing528.com)
有些用户需求过于零碎、细化，不足以构成一个独立的用户需求，类似的这种情况也不适合写到Product Backlog项中。
（3）无特殊情况不做变更。
如果不是因为用户需求变更等外部因素影响，团队内部的因素导致的Product Backlog项变更应当尽量避免。
Product Backlog还应当做到可视化，即让敏捷开发团队、利益相关者等都能非常容易地看到其内容、状态和进展。可视化在需求阶段显得尤为重要，有助于敏捷开发团队纠正未必准确的认识，加深对用户需求的理解，有利于后续的敏捷实施。
Product Backlog的意义在哪里
Product Backlog根据用户价值优先级别罗列出产品需求，通过简单的展示，我们可以认识整个项目规模，确定发布计划和迭代计划。Product Backlog为敏捷团队指明了产品开发目标，使团队对将要实施的事情有整体认识，明确产品将会是什么样子，将会给用户带来什么价值，以及进一步思考并明确团队现在所处的状态。
Product Backlog是动态变化的，以下场景都会导致变更：
●用户需求未变，列表级别过低或者内容陈旧，开发成本远大于需求本身的价值。
●用户需求未变，Product Owner与Team讨论后需要调整预估时间或者优先级顺序。
●用户需求未变，Product Owner与Team讨论后拆分、合并或删除用户故事。
●用户需求未变，但是用户需求依赖的环境发生变更。
●用户需求变更。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
