Scrum论坛

Scrum要求在Sprint结束前至少有一个有用且有价值的产品增量，这是非常重要的。

我想知道，你们的产品负责人是否理解不是每个增量都需要在Sprint结束时发布给客户?

为了提供价值，增量需要是可用的。是否有机会从Sprint评审的涉众那里获得经验反馈，基于您所描述的拆分产品待办事项的项目?每个Sprint是否会减少一些风险?您的方法是否有助于团队验证假设?

考虑到目前没有任何方法检查产品目标的进展和最新增量的情况，您建议的方法似乎是合理的。

产品增量很大，PO不想切片，因为不会增加业务价值

他准备好了吗飞跃-的-信仰这需要吗?如果事实证明这不是真正需要的，价值也不存在，那该怎么办?

每次Sprint都是一个学习的机会，通过这个机会我们的假设得到了经验验证。这听起来好像PO正在让他自己和团队为一系列错过的机会做好准备，而在这些机会中产品风险本可以得到更好的控制。

嗨，萨拉，我理解你的痛苦，根据我的经验，当订单实际上是一个中小企业时，这种情况经常发生，可能不理解对未完善的东西获得反馈的价值。一般来说，中小企业从一个相当完美主义的立场开始，因为他们涉及客户领域，甚至可能在那里有声誉。

我所解释的最好的方法便是区分发行计划和sprint计划之间的区别。他们可能认为他们对发布的样子有一个相当精确的概念，但他们真的想在与最终客户验证之前隐藏数月吗?PO必须在团队和scrum过程中建立信任，并质疑他们想要的是否是他们真正需要的。

当然这是一个困难的问题，但把它看作是路上的一个驼峰，你不可避免地需要在开始时进行大量的对话，但尽早解决这些问题是值得的。

查看过去订单的功能(查看订单列表、按日期搜索、按订单id筛选并单击订单以显示订单详细信息)

嗨，sara，我是这么看的——这是否足以显示订单列表，而不给用户排序或过滤，或不提供订单的详细视图?

作为终端客户，我觉得仅仅分享订单清单是不够的。这不是一个完整的解决方案。

我同意PO的说法。

我的观点……

增量需要对涉众有价值。然而，最终用户并不是唯一的涉众。在某些情况下，Scrum团队本身就是涉众。因此，提供有价值的有用的增量并不意味着客户可发布的增量。

在您建议的情况下，开发人员很可能会按照您所描述的方式构建功能。我以前也做过几乎完全相同的顺序系统。在很多情况下，开发人员首先构建清单。我们将其展示给涉众，并得到了一些有价值的反馈。诸如列的顺序等反馈没有首先显示最重要的数据，字段标题的措辞具有误导性，一些字段在清单中不需要，但在查看详细信息时是需要的。这有助于我们简化解决方案并节省时间/金钱。我们也得到了一些反馈，如该功能将主要用于移动设备，数据的格式需要考虑到这一点。这实际上意味着额外的工作，但最好在开始时就知道这一点，而不是等待结束。

敏捷交付的迭代方法并不总是意味着涉众一次性得到整个解决方案。但是它确实有助于确保当完整的解决方案交付时，它将是涉众能够立即使用的解决方案。