故事点和业务价值是否相关?
PO通过与开发团队合作将交付给最终用户的价值最大化，但(在我看来)用于交付功能(或故事)的故事点可能与交付的业务价值密切相关，也可能不密切相关。
故事点/速度帮助开发团队计划他们的工作，并有更好的交付可预测性。另一方面，业务价值是交付给终端客户的内容以及他们如何接收它。来自客户的反馈是了解交付价值的好方法。与开发该特性所需的故事点相比，交付的特性对客户的价值可能相同，也可能不同。
另外一点，故事点可能会因团队为特性/故事实现所采取的方法以及团队如何理解其复杂性而在组织内部的团队之间有所不同，但交付的业务价值不会因团队如何感知该特性/故事而改变。
请分享你的看法。
故事点与商业价值无关。他们倾向于难度、复杂性和完成所描述的工作所必须付出的努力。
Ron Jeffries最近写了一篇博客其中包括极限编程中的要点的简短历史，这些要点被采用到其他敏捷方法中，比如Scrum。
我要在这里提出一个不同的意见。
是的，故事点并不直接等同于价值。它们是由完全没有内在意义的数字组成的，只是为了帮助我们获得关于过去的更好的数据，以便我们在当时做出更好的决定。
然而，我们仍然基于价值为我们的待办事项排优先级。东西是大是小并不能告诉我们它应该在backlog中的什么位置。
如果采购订单在做他们应该做的事情，并且没有其他外部压力，那么选择做一个更大的项目通常只会发生，因为它是一个更有价值的项目。
因此，你绝对应该能够(抽象地)将点数与价值等同起来。事实上，如果你做不到这一点，那就说明我们正在使用一些非常奇怪的逻辑来决定什么应该排在backlog的最前面。
如果我们选择8分的项目而不是5分的项目，8分的项目应该更有价值，这意味着本质上，如果所有的分数相等，多3分在某种程度上意味着更多的价值。
这听起来可能很愚蠢，但我实际上试图让团队以这种方式思考问题。否则，我们很自然地开始将数字视为时间或努力的衡量标准，而成功就是“做更多的工作”。
通过理解一个更大的项目应该更有价值，否则为什么要做它?这推动了正确的行为。
这是一个高级的话题，我一般不会从这里开始，但一旦团队掌握了评估的基本知识，我认为这种思维方式是非常强大的。
距离我上次评论这个话题已经过去几年了，我的看法有了一些改变。
我同意你的说法:
是的，故事点并不直接等同于价值。它们是由完全没有内在意义的数字组成的，只是为了帮助我们获得关于过去的更好的数据，以便我们在当时做出更好的决定。
因为每个人对于故事点的含义都有不同的概念，所以我们并没有真正的方法去提供它们的“普遍”用途。最好的办法是让组织或团队提供它们的含义的定义，所有人在处理故事点时都使用这个定义。但即使在这个模型中，每个人在应用它们的方式上仍然有一定的自由，所以不能保证一致性。
故事点只对使用它们的团队有用。
故事点是否等同于价值?有可能，如果使用它们的团队在提供分数时考虑到了物品的价值。
我个人的立场和我所提倡的观点是，故事点除了是基于你今天所知道的信息去猜测复杂性和努力之外，并没有任何内在价值。它不用于任何类型的测量。它仅由开发人员在将一组产品待办事项列表项拉入Sprint待办事项列表时使用，以决定他们是否认为工作主体可以在Sprint边界内完成。价值是由项目交付给涉众时的影响所决定的。它们中的任何一个都不能被一个数字充分地捕捉到，因为它们都是本质上固有的。
