为什么敏捷团队应该做两级估算

作者：Mike Cohn

译者：Tao Zhang

校审：Lance Zhang

对于敏捷团队，尤其是Scrum团队来说，对产品待办列表和Sprint待办列表进行估算是件很常见的事情。在本文中，我将会介绍：

• 为什么既估算产品待办列表，又估算Sprint待办列表看起来很多余，但是却很有用
• 为什么团队在估算产品待办列表和Sprint待办列表时应该采取两种不同的单位
• 团队应该在什么时候估算
• 是否任何团队都应该做估算

如果你不熟悉敏捷，或者需要快速复习一下产品待办列表和Sprint待办列表是啥，可以看看关于产品待办列表和Sprint待办列表的视频。

为什么要同时估算产品待办列表和Sprint待办列表？

同时估算产品待办列表和Sprint待办列表非常有用，因为估算它们的目的是不一样的。

估算产品待办列表的目的

需要去估算产品待办列表的主要原因有三个。

首先，团队和产品负责人需要对到某个时间点可以交付什么样的价值做出一个长期一点的预测。这使得团队可以应对下面的问题：

• 在三个月内可以交付出多少东西？
• 这一系列功能啥时候能交付？

其次，它可以帮助产品负责人进行优先级决策。工作项的优先级应该基于它的预期收益和实现成本。当一个工作项的估算是3个故事点，或者3天又或你想使用的任何单位，通常优先级都要比它的估算值是100时要高。

如果不是这样，则意味着你总是在喝最好的葡萄酒，或者开最好的车，不管价格如何。那1945年建的木桐酒庄-罗斯柴尔德城堡里还会有人吗？

我们大多数人，包括敏捷项目的产品负责人，都无法用不考虑成本的方式做出决策。所以在确定工作的优先级时，我们需要考虑开发它的成本。对于大部分的工作项，所涉及工作量的估算是其成本的最大组成部分。

对产品待办列表中的工作项进行估算的第三个目的是，团队成员通过充分的考虑和估算，可以对产品相关工作项有更多的了解。这就意味着将来在开发该功能时不会有太多“惊喜”。 

估算Sprint待办列表的目的

现在，我们再来看看为什么团队还应该对Sprint待办列表进行估算。其中有两个目的。首先，它可以帮助团队确定有多少工作需要放到当前Sprint去完成。

通过将工作项分解为独立的小任务，然后在Sprint计划会上粗略地对它们做出估算，团队可以更好地评估工作负载。这增加了团队完成他们所承诺工作的可能性。

其次，在Sprint计划会上确定并估算任务可以帮助团队成员更好地协调工作。例如，如果没有对Sprint待办列表做过估算，则团队可能不会注意到完成迭代工作的关键路径，或者在这个迭代中某个角色比如设计师将会比其他人更加繁忙。

为什么要以不同的单位进行估算？

由于对Scrum团队的两个不同待办列表进行估算的用途是不一样的，因此估算所使用的单位也应该不一样。

特别是对于产品待办列表项，估算的效率至关重要。

我们来看看原因，假设老板要求团队估算啥时候可以交付40个用户故事形式的产品待办列表项。

这完全可能是个合理的请求。如果项目花费的时间太长，老板可能想知道是否需要再多加几个人到团队里。又或者，老板只是希望在某个合理的日期来启动项目。
如果团队要通过将每个用户故事分解成任务然后去估算每个任务来回答老板的问题（如在Sprint计划会中通常所做的那样）那么估算所花费的时间将是巨大的。

假设我们要平均进行15分钟的讨论并估计每个用户故事（这是Sprint计划会中通常需要的），那么把40个用户故事估算完将需要整个团队600分钟（10个小时）的时间。

如果团队可以对产品待办列表项使用更高层次但同样差不多准确的估算，则通常可以搞得更快一些。我建议团队能平均在三到四分钟内估算一个产品待办列表项。这样的话，估算40个用户故事将花费不超过160分钟，即大约2-½小时。

所以最好的方法是让团队按故事点估算其产品待办列表项，并按小时来估算其Sprint待办任务。

这种方式之所以能很好地起到效果，是因为故事点是一种具有不同优势的团队成员可以达成共识的更抽象的衡量标准。正如你和我可以就“一只脚”的长度达成共识一样，即使我们的脚极有可能长度不一样也没关系。这样具有不同技能的敏捷团队成员也可以就某个用户故事所需完成的工作是前一个的两倍达成共识。

但是，故事点在Sprint这个级别不会起作用。在进行Sprint计划时，请记住目标是确定团队这个Sprint要进行的工作量。对于诸如故事点之类的抽象单位而言，这很难。用小时数就要简单很多。

在Sprint待办列表中用小时数进行估算是可行的，因为Sprint所包含的项目通常少于整个产品待办列表项列表，这意味着它不会花很长时间。另外，通常Sprint内一个任务只会由一个人来执行。而且在很多情况下，一个任务产生后就能够很清楚谁会去做它。这些因素使得以小时为单位来估算SprintBacklog成为可能。

什么时候进行产品待办列表的估算？

众所周知，在创建Sprint待办列表时， Sprint待办列表项估算是Sprint计划会的一部分。但是，团队应该在什么时候进行产品待办列表项的估算？
我建议在两个不同的时间点去估算产品待办列表项。第1个估算的时机，是在故事写作研讨会之后的一到两天。

我建议这是一个产品负责人应该大概每个季度都要组织团队进行的会议。会议目的是识别出所必需的用户故事，用于实现若干个版本计划（每个计划通常大于1个Sprint）。我们可能会花2-4个小时（每季度）去识别这些产品代表列表项，然后再花1-2个小时再对它们做出估算。

以Sprint为周期，如果自上个Sprint以来，产品待办列表中的事项有更新，则这是团队第二个对产品待办列表项做估算的时机。这个可以随时去做，但最好是在一个Sprint相对靠后的阶段，以最大程度地避免在下个Sprint开始前又出现新的用户故事。通常，这可以在团队的产品待办列表项梳理活动上完成，或者在每日站会后紧接着进行，趁着团队每个人反正已经处于中断状态而且都在场。

延伸阅读：估算是一种很难的东西，如影～随行～

为什么在Sprint计划会上不要对产品待办列表项进行估算？

在Sprint计划会议开始时估算产品待办项目听起来像是个好主意，但是，这会有两个大问题。

首先，这时候才考虑估算值来调整优先级对于产品负责人来说太晚了。

请记住，团队完全估算其产品待办列表项的原因之一是使产品所有者可以确定优先级。如果直到开始进行Sprint计划之前都没有给产品所有者提供估算值，那么假设产品所有者在确定优先级时会充分考虑这些因素是不现实的。

其次，在Sprint计划会议开始后估算产品待办列表项的团队往往在估算上会花费更长的时间。

我想这是因为团队成员即将要进行更详细的Sprint计划，在这个想法的潜移默化下，通常会在对产品待办列表项进行估算的时候引入更多的细节，这就使得，相对于我所设定的每3-4分钟估算一个产品待办列表项的目标，团队要花费更长的时间。

基于这些原因，请试着在Sprint计划会之外去估算那些新的产品待办列表项，并且还要在Sprint中尽可能晚的时间点，在大部分新的用户故事（如果不能全部的话）已经确定之后。

是否所有团队都应该估算？

我已经阐述了是有充分的理由去做产品待办列表和Sprint待办列表的估算的。同时讨论了这些估算应该以不同的单位（故事点和小时数）并且在不同的时间点进行。
但是，这些论点是否适用于每个敏捷团队？还是说有些团队不需要去估算这两个待办列表中的某一个甚至都不需要？

我将在周四的“每周小贴士”中来分享我的想法。如果您还没有注册，那么可以注册一下，就能在每个星期四收到一个我关于如果成功运用敏捷的小贴士。
您的经验是什么？

您的团队如何估算产品待办列表和Sprint待办列表？您是否使用相同的单位？您在什么时候做估算？请在下面的评论中也分享下您的经验。

原文链接：https://www.mountaingoatsoftware.com/blog/why-agile-teams-should-estimate-at-two-different-levels/

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.