身为产品经理，你是否也曾为用户故事的积压的问题苦恼过？本文作者介绍了一套体系方法，通过决定用户故事的优先级来解决这个问题。

上个迭代还有好几个用户故事没有完成！

燃尽图没有燃尽是因为出现了 Bug……

上述的吐槽听起来是不是很熟悉？

我身边的产品经理基本上都经历过这样的事情。可以说，用户故事的积压和产品的缺陷对于产品经理们来说应该是家常便饭了。

深究其原因，我认为是大家缺乏一套体系的方法来决定用户故事的优先级。

所以在这里，我想以自己的团队为例，给大家介绍我们正在使用的排用户故事和 Bug 修复优先级的工具框架。

一、为用户故事排优先级

我的团队采用了一套「故事排名系统」。

这套系统是这样的：我们把紧急度和商业价值这两个维度在 1 – 5 的范围内取一个值，然后把这两个数相乘以确定一个用户故事的最终权重。

我们把权重标在一个矩阵上，用这种方法对产品路线图中的用户故事进行可视化和排列优先级。

在实际工作中，我会为每个用户故事制作一张分值卡，上面有两个打分项：紧急度和商业价值。

紧急度的取值与三个因素有关：交付时限、任务依赖和直接后果。

举个栗子：一个紧急度为 1 的用户故事可能没有时间限制、影响很小，而一个紧急度为 5 的用户故事可能时间紧迫并依赖很多其他用户故事，如果不先把它完成就不能推进其他的故事。

商业价值的取值也与三个因素有关：客户影响、品牌或声誉影响和竞争优势。

再举个栗子：一个商业价值为 1 的用户故事可能只对很少的客户／用户有影响，而一个商业价值为 5 的用户故事则对每个客户都很重要——也对公司生存很重要。

怎样确定每个用户故事的分值呢？可以使用紧急度排序表来确定。

说了这么多，我们给每个用户故事分配了紧急度和商业价值这两项的数值之后，怎么决定用户故事的轻重缓急呢？

你要做的，就是把每个用户故事放入这个矩阵。在实际使用中，我发现老板和公司更喜欢晚一点再对付取值 6、8、9 的用户故事，所以我根据实际情况「修订」了一下矩阵。

二、为产品 Bug 排优先级

在我的团队推广了用户故事优先级这套方法之后，我们把主要精力放在了对付产品 Bug 上面。

有一天我灵机一动：能不能用同样的方法对付 Bug 呢？当然可以，只不过矩阵上的横纵轴要改一下：横轴从紧急度变成影响范围，纵轴从商业价值变成严重性。

每个 Bug 仍然分配从 1 到 5 分配一个取值，然后把这两个数相乘以确定一个 Bug 的最终权重。

与用户故事类似，我也为每个 Bug 制作了一张分值卡。

与上文中的用户故事一样，这里也要说明一下 Bug 的两个打分项：

Bug 的影响范围与受影响的用户数和产品功能相关。举例：影响范围为 1 的 Bug 只牵涉少数用户或产品功能，而影响范围为 5 的大 Bug 则会波及所有用户和大多数产品功能。

Bug 的严重性取决于解决它的难易程度。再举例：严重性为 1 的 Bug 可以代表错别字或者美工问题，但严重性为 5 的 Bug 可能意味着损坏或丢失数据，或者让产品完全不能用。

我们得到了这样一个 Bug 优先级矩阵，并根据实际需要做了微调：

一点心得

我的团队通过使用这两种优先级工具，居然能够有条不紊地顺着 Bug 列表来开展工作，这在以前是不可想象的。

通过这两种工具，我们不仅产品质量有了提升、而且流程精简了许多。

通常我们会先把想法扔进 Aha!，然后再把用户故事或 Bug 放入矩阵排列优先级。像这样：

不知大家对这种排产品列表优先级的方法有什么看法？又或者，各位在自己的团队里平日有什么好的做法？欢迎在评论区里共同交流进步~

编译自：https://tpgblog.com/2017/10/16/how-to-quickly-prioritize-your-product-backlog/

原作者：Christopher Davis

作者：「即能小程序」，公众号：「即能学习」

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

题图来自 Unsplash，基于 CC0 协议