在我的一系列帖子中“如何通过10个简单步骤实施Scrum“，我指的是估算的两个阶段：
步骤2是 如何估算您的产品积压.
步骤4是 评估Sprint计划中的任务.
最近有人问我一个很好的问题– 为什么要估计两次？ 我认为值得在这里解决这个问题…
这个想法是， 点数，是产品待办事项列表上所有内容的高级估算。
在估计分数时，团队几乎没有真正需要什么或功能必须做什么的详细信息。它们可能是根据简单的标题或描述进行估算的。
这种高水平的估算有助于进行中期计划（发布计划），并有助于产品所有者在某种程度上确定各个功能之间的相对关系，从而对所有事项进行优先级排序。
后来，这些点被用于计算Velocity，这意味着团队在统计上可以更好地预测从非常快速的高级估算中可以实现的目标，这显然非常有用。
第二个估计值仅是对下一个Sprint中包含的那些内容的详细估计。
在这里，团队有机会潜在地查看需求的某些先前分析，与产品所有者和任何其他利益相关者讨论功能，并与团队讨论技术含义。
在此阶段，团队可以更好地将功能分解为任务并在数小时内进行估算。
在此阶段，还可以考虑团队’当时的实际容量–即有多少个团队成员可用于冲刺，任何其他承诺，假期等。借助这些信息，团队应该能够合理准确地计划下一个冲刺。
我发现有些团队喜欢第二次Sprint Planning估算，而其他团队则可以不用它们。
没有进行此操作的团队仍将召开Sprint计划会议，他们仍将使用该会议来讨论下一个sprint中功能的需求和技术设计，但他们没有’不必尝试将功能分解为任务并在几个小时内进行估算，因为它们始终会发现它们始终是错误的，因此这浪费了所有人’的时间。估算最准确的团队可能是发现它对计划最有用的团队。
减少工时估算的团队完全依靠他们的历史速度（以点为单位）来决定每次冲刺需要投入多少，因此他们让统计数据来处理。
如果对于任何一个Sprint，他们都缺席很多，或者团队成员失踪了，那么他们只会降低速度。
我个人比较喜欢这种方法。它’非常好用，简单，根据我的经验，估计的统计方法与分析方法一样准确，即使不是更多。分析性估算的麻烦在于，您只能估算自己可以想到的东西，而不可避免地可以’真的没有想到一切。即使您认为可以。
不过，我可以肯定地说的是，无论您是分解任务还是估算任务，Sprint计划会议对于团队一起讨论下一个Sprint仍然非常有用。
如果你没有’t discovered it, I’在我的博客上写了很多有关敏捷评估的文章。您可以在这里查看我关于该主题的所有帖子– 敏捷 Estimating.
凯莉
摄影者 杰罗尔德利
