众所周知，决策是在一定约束条件下，为实现个人、团队或企业目标而按照一定程序和方法，从备选方案中择优选择一个最合适方案的过程。
因此，任何决策都要作出某种选择，而选择是否正确，取决于对决策对象的认知和价值判断是否正确。决策离不开价值判断。
软件开发行业也是如此，特别是在敏捷开发中，很多时候都是根据业务价值来决定特性或故事的优先级排序，可以说，业务价值是敏捷观念的核心。
那么，人们为什么要关心业务价值呢？Joe Little梳理了四个原因。
原因一，这个世界上有无数有趣的事情值得去做，所以，问题就不在于是否能找到有趣的事情去做，而在于决定哪些是最重要的需要去做的事情。这正是我们关心业务价值的原因之一，人生苦短，总要去做一些“真正有意义”的事情。
原因二，业务价值有利于保证团队成员共享一个一致的目标，来判断他们的行为是否正确。可以说，业务价值调动了团队成员的自然动机，并给了他们一个基点，可以将与团队工作相关的任务按照自然的顺序进行排列（比如谁做什么，系统架构怎么做等）。
原因三，在软件这个充满了变数的混沌世界中，把握业务价值可以给人一种处变不惊的魄力。变化是永恒的，这包括人们的遗忘、客户群体的变化、客户需求的变化、之前的评估渐渐失效等等。但只要我们对业务价值有适当的理解， 它就可以在这变化的漩涡中充当一个恒定的标杆。
那如何判断业务价值的高低呢？Pascal Van Cauwenberghe认为，如果是先编写用户故事，然后再估计它们的业务价值，这一做法会存在严重的缺陷，因为我们很有可能在前期浪费大量时间在低价值甚至是零价值的用户故事上。
好的做法是首先回答这个问题：“我们如何才能找到传递了业务价值的用户故事？”这显示了一个不同的过程，即我们需要首先定义我们打算实现的业务价值，然后生成那些有助于业务价值实现的用户故事。
落地到具体执行过程中，可以按以下步骤来进行：
而实现这些业务流程的用户故事显然有助于业务价值。
然而，尽管大家都知道业务价值、以及依据业务价值做决策的重要性，但在实际的项目过程中，我们依旧会遭遇各方面的挑战，比如：需求来自多个方面，每个业务人员都将解决自己的问题视为首要优先级事项；领导拍脑袋提出的不合理要求极有可能会打乱原有计划。这样被动的需求接收模式让研发团队很难坚持进行业务价值判断。
对此，姚安峰认为，我们在执行中应该换一个方式。首先，包括技术、PO、业务人员在内的项目团队以及其它相关利益者需要共同理清产品的愿景。也就是要弄清楚为什么开发这个产品？对它的期望是什么？什么是这个产品主要的卖点？相比旧的版本或其他竞争对手，这个产品能带来的改进或差异化竞争力在哪儿？是不是项目相关的各方人士都理解并认可该愿景？该产品的愿景是不是与组织战略方向一致？
明确了愿景后，我们就要对如何达成这个愿景进行规划，产生演进路线图。任何产品都有一个从探索到消亡的过程，都将遵循产品生命周期法则。比如一个在线教育应用，当前的目标是在6个月内发展一定用户基础并获得反馈。那在这个阶段，一个吸引人的用户推荐系统是不是更有助于实现目标？一个健壮的会员管理功能呢？一个完善的收费会员体系呢？显然有不同的答案。
产品生命周期决定了在不同的阶段产品应该有不同的策略，从探索期，发展期，成熟期，直到衰退期，“业务价值”的内涵是一直在改变的。而产品规划是预测性地对这些阶段进行设计，并制定每个阶段应该采取的策略，这其中就包括每个阶段的价值取向。更进一步，大的阶段还可以分为一系列连续的小阶段、小目标，比如每个季度或每个月都应该有一个产品要达成的关键目标。
有了团队一致认可的阶段性目标后，当团队分析一个特性或故事时，基本只要看它们与目标的相关性就可以了。只有与该目标强相关的特性或故事才能被优先纳入版本计划或迭代计划中，而与目标不强相关的优先级就往后放。如果这样做出来的计划大家认为不合理，那就要回去重新审视之前设定的目标是否不恰当了。产品的特性或故事是否符合产品规划、是否符合当前的阶段性目标是进行“业务价值”判断的最重要方法。
在基于阶段性目标进行“价值”判断时，建议从“是否不可替代”的角度进行思考，即对每一个特性或故事都问问自己：如果暂时不实现它，我们想要进行的探索能否达到目的？想要改造的业务流程能否实现？用户的期望能否得到满足？是否可以暂时采用其它替代的手段达到同样目的？
如果我们每一次都把目标设定得足够小，这样的思考就可以帮助我们排除很多暂时价值还不够高的工作，从一堆看似都和当前目标相符的特性或故事中找出真正价值最高的部分，从而更快将一个版本交付出去。
上面分别谈了谈进行业务价值判断时需要认真思考的几个角度。可以看出，进行价值判断需要考虑很多因素，但如果为了避免判断错误却花过多时间进行讨论，而迟迟不去实践，反而会错过实现价值的机会。在互联网和传统企业都努力追求创新的的今天，需要的是快速迭代与反馈验证，以及基于反馈的快速调整；而所谓准确的预测、判断并不能有效避免失败，只有基于快速反馈验证的迭代式演进才能降低可能失败的风险。
最后，需要注意的是，所有这些分析和判断都是在特性或故事被实现之前进行的，是一种预测。而预测是导致绝大多数失败的恶魔，只有实践才是检验真理的唯一标准。