说明：这篇文章的内容同样来自《Fifty Quick Ideas To Improve Your User Stories》，只是相比系列文章的上一篇跳过了一些章节。因为觉得这部分内容特别有指导意义，所以先写这部分内容。
根据增长阶段来决定优先级
开发新产品的团队经常为了协调不同项目持份者的优先级要求而斗争，在目标各不相同的用户故事间摇摆不定。这些故事有些是为了提升短期销售额，有些是为了保持长期持续发展，还有些是吸引新用户的市场动作。所有这些目标都是必要的，因此要在它们之间保持平衡是很困难的事情，尤其是对资源有限的小型团队而言。
Alistair Croll 与 Benjamin Yoskovitz 写的《Lean Analytics》中介绍了成功的项目共同拥有的增长模型，这个模型一共分为五个阶段。
第一个阶段叫“共情”（Empathy）。这个阶段需要针对真实的问题想出一个用户愿意付费的解决方案。
第二个阶段叫“粘性”（Stickiness），这个阶段需要构建正确的产品以留住客户。
第三个阶段叫“裂变”（Virality），有计划、有目的地扩大用户群。
第四个阶段是“收入”（Revenue），在这个阶段以适当的利润、在健康的生态环境中建立起可持续的、可扩展的商业模型。
第五个阶段是“扩张”（Scale），即使业务持续增长。
虽然这些名字更适用于消费类软件，但是B2B的软件有着类似的发展阶段。企业内部的开发项目可能不太适用这个模型，但是对于这些软件一样需要在开始大规模开发以前先确保解决的是正确的问题。
上述发展阶段模型为确定用户故事的优先级建立了一个很重要的框架。例如在能够留住用户、有一定客户粘性以前就致力于裂变式增长就是一种浪费。因为即使能够吸引来大量用户也无法留住他们。
如果要使用上述模型，那么首先需要所有的项目持份者都能够对当前所处的发展阶段达成共识。前文说过，好的用户故事应该能描述清楚行为的变化，而在每个阶段只有很少的行为变化是真正重要的。
例如，大部分处在“粘性”阶段的用户故事会聚焦于提高用户使用产品的频率、更多个“回头客”、长期使用产品。
使用目的一致性模型来决定优先级
MoSCoW 模型将功能分为“必须有”（Must have）、“应该有”（Should have）、“可以有”（Could have）、“希望有”（Would like）四个级别。这个模型似乎是确定工作优先级的标准方式。但这个模型（包括其它一些优先级模型）最大的问题是，大部分的项目最终都落在了“必须有”这个级别里。
由Niel Nickolaisen 在《Stand Back And Deliver》中提出的“目的一致性”（purpose alignment）模型是避免上述问题的好方法。这个模型要求持份者对每个有待确定优先级的工作问两个问题：
- 这是关键性任务吗？（是否离开它业务就无法开展了？）
- 这个工作会带来市场区分度吗？（它是否会带来客户、提供竞争优势或者其它类似的好处？）
一旦这两个问题有了答案，所有的工作可以被划入以下四个类别：
- Differentiating (差异性)：即是关键性任务、又能带来市场区分度。这是组织的主要投资方向。对这些任务，不仅要“足够好”，而且要达到“杰出”的程度。
- Parity（均势）：关键性任务，但是没有市场区分度。这些是必须要做的事情，但是只要做到“足够好”够了。追求在这些方面远超竞争对手是一种过度投资。
- Partner（伙伴）：有区别于竞争对手的机会，但不是关键性任务，例如在移动设备上拓展实验性的销售通道。
- Who cares （无关紧要）：即不是关键性任务，也不会带来市场区分度。
Partiy类别的任务适合使用现成的解决方案或产品、外包或者只做到可能可以成功的最简单的事情。对这个类别中的用户故事应该首先考虑集成已有的软件而不是自己从头开发。
Partner 类别的项目市场上往往没有开箱即用的方案，但是组织内部一般也没有相关的专业知识，这种情况下最好与拥有必要知识的合作伙伴共同开发。
根据目标一致性模型对任务分类有助于组织重新确定资源的投向。例如对于客户服务部门来说，问题跟踪系统是必须要有的。但是对于大多数组织来说，问题跟踪系统并不会提供竞争优势。已经有太多的组织浪费了大量的时间和金钱建设自己的问题跟踪系统。除非与众不同的处理客户问题的过程能切实带来区别于竞争对手的竞争力，否则最好改变组织内部的流程以适应产品化的解决方案，或者请第三方在已有系统的基础上进行定制，但是只到“刚刚够好”（just-good-enough）的程度就可以了。
相比MoSCoW模型，“目标一致性”模型提供了两个“必须”类别：Differentiating和Parity。两者不同处在于，Differentiating创造价值，Parity提供必要的基础。
“目标一致性”模型最初是用来分析业务过程而不是软件功能的。因此我们在分析用户故事时，应该要针对“价值语句”部分（“为了…”）应用“目标一致性”模型，而不是功能部分（“我需要……”）。如果已经有了非常多的用户故事，那么最好先根据所属的业务活动或者影响的领域进行分组，然后再应用“目标一致性”模型。
需要注意的是，当商业机会发生变化时，业务活动所属的类别是会变化的。例如前面例子中的移动销售渠道的例子，当这个渠道成为主要的收入来源时，也许需要将它移入Differentiating类别。