在Scrum评估中讨价还价和失败的尝试是否合法？
我在Scrum会议中注意到，开发人员通常会对故事进行现实的估计。但是，即使是相当简单的故事，也需要大量的精力进行配置，设置第三方组件，测试和最终构建，并且系统积累了相当多的技术债务，因此对于产品所有者或管理层来说，估算值通常显得过高。 PO经常尝试降低此类估计，例如：“什么，您想要这个故事要13个故事点（4天），这不可能！我无法向管理层解释，有人应该可以对此进行编码3 SP [在4小时内！！”。结果，开发人员不得不屈服于做出5或8个故事点（1.5至2天）的估计值（Scrum估计值仍被视为承诺，而不仅仅是预测）。 当然，如果没有任何降低期望的计划（主要是在测试和质量方面），则这些冲刺经常会失败。开发人员的估算是诚实，现实的估算，击败估算并不会降低实际的工作量。 可以说：“您不应该做出不可能的承诺，只是因为有人逼着您去做！” 但是我认为，开发人员的工作是软件设计和编码，而不是讨价还价或承受压力！可能有各种各样的交易，通常是直接与外部客户打交道的交易，但这并不是大多数Office开发人员！ 对我而言，这种做法只会使程序员看起来像个混蛋，会导致不断出现的sprint故障，并阻止了实际的估算，同时也寻求了实际的改进。 Scrum准则对此主题有何看法，或者他们对此有何表述？ 编辑：用故事点代替时间。我指的是规划扑克和故事点的初始估算阶段，而不是任务详细计划。我只是把日期/时间放在这里，因为有时是典型的对话，有时是用时间而不是时间。抱歉给您带来任何混乱！故事点示例比时间示例代表更长的时间段。 编辑2当前没有专门的Scrum主持人，而PO在评估会议时扮演着这个角色。因此，可能是角色冲突使这种不适当的讨价还价变得更糟，因为他是作为权威而不是中立或开发者的混乱大师出现的。也许，只要没有候选人，就可以将他作为有偏见的参与者而不是“大师”来解决。