敏捷评估阶段

Question

我对敏捷评估的以下要素感到困惑：

• 每一个积压的故事都应该用故事点来估计吗？如果是，由谁提供这些估计数。
• 或者，故事估计是否应该是斯普林特计划的一部分？
• 故事什么时候被分解成技术任务，由谁来完成？
• 技术任务是否以小时计算？如果是，由谁提供这些估计数？
• 如果故事和任务是用不同的单位来估计的，你用什么来测量速度？

在许多情况下，这些问题的答案是，您需要找到对您的团队有效的方法。虽然这是合理的，但很高兴听到什么对其他球队有效。

Answer 1

在我的经验中，以下内容工作得很好，但无论是敏捷还是Scrum都没有规定：

• 您确实可以在“故事点”中估计Product中的每个故事，除了Spikes之外。开发团队提供估计值，因为他们是将要做这项工作的人。
• 故事估计通常是产品积压精化或Sprint计划的一部分
• 用户故事通常在Sprint计划期间被分解成任务，有时在产品待办事项处理过程中被分解成任务
• 任务通常以小时计算。开发团队提供评估，因为他们是那些将要做的工作。
• 用户故事被用来测量速度，因为速度是在Sprint中“完成”的故事点的数量

Answer 2

据我所做的实验：

清理积压会议可以用来估计故事点中的故事。我们建议这样做，在短跑计划之前，这样我们就不需要再关注估值了(嗯，主要是)。

计划扑克可以用来让开发人员估计故事。产品所有者不应该估计，因为The development team members need to make a commitment about how much functionality they will complete in the upcoming sprint。

关于分拆技术任务，恐怕我自己还在寻找答案。