Scrum:应该估计不规则事件吗？

Question

Scrum团队是否应该评估不规则、计划好的事件，比如对新用户和潜在客户的概述/演示？我们的团队很小，所以准备和执行这些事件的工作落在我们(主要是产品负责人、测试负责人和Scrum )身上。我们甚至让我们的整个团队为他们的一部分做了记录，记录了用户的互动和反馈。

作为Scrum大师，我相信这些会议是间接的，不应该被估计。它们不会直接增加软件的价值--它们的主要产物是生成新的积压故事和识别感兴趣的客户。然而，团队不同意我的观点，因为他们在这些事件上付出了很大的努力，这是可以理解的。在我看来，更大的问题是我们的团队成员负责协调和以某种方式参与这些活动。他们应该不受这些任务的影响，我认为我们不应该仅仅因为没有其他事情可做而妥协。

谢谢你的意见。

Answer 1

想想看:如果你的团队花了4周的时间来做一个30分钟的演示，那么很明显有些事情是不对的。同样，如果他们在那次会议上花了12个小时，你会想知道发生了什么。

这些都不是我提供的合理数字。当然，还需要更合理的数字。这个例子仅仅是为了证明一条线存在，所以估计它在哪里是有意义的。

然而，下一个问题是错过最后期限会带来什么后果。在开发中，它可以是问题代码库(用于维护的hrd)或问题开发人员(不是不做他们的工作，也不是在为完成他们的工作而挣扎)的第一个指示。

但同样的标准不适用于新用户(培训)和潜在客户(销售/营销)的概述/演示。

一个需要更长时间的训练可能不是一个坏学生(或一个糟糕的老师)的迹象。一个需要更长时间的销售宣传并不意味着一个问题，如果它实际上增加了销售该产品的机会。

评估是否被用作证明开发人员将时间花在非技术管理上的一种方法？那么你应该对估计值设定一个合理的限制。任何偏离估计的行为都可以通过指出事件的不可预测性来证明其合理性。

这和执行任务没什么区别。一些bug在几分钟内就被修复了。其他的则需要几天或几周。你不可能总是知道一个问题需要多长时间才能解决。估计的要点不是正确的，而是划出reasonability__的界限，所以您不需要干预任务，除非有人提出了危险信号，或者检查了估计值，但仍然没有交付。

在我看来，更大的问题是我们的团队成员负责协调和以某种方式参与这些活动。

如果您的意思是您的开发人员不应该做这个工作，而其他人应该做它，我不太同意。

如果您的意思是您的开发人员在这方面的时间不应算作开发时间，那是正确的。

作为一个简单的例子，假设您的开发人员之一也是一个天才会计，而会计部门急需一双额外的手。会计部门不能告诉你他们需要他多久，他们说的只是“直到账簿正确”。

对你来说，对会计任务进行评估是没有意义的，因为你不是一名会计。其次，会计成功的衡量标准不是用预测结果的能力来衡量，而是用实际结果的精确性来衡量。

在这种情况下，您需要考虑这些演示/演示是“开发缺勤”，即员工(不是开发人员)正在为公司做一些事情，但没有执行开发任务。

但其逻辑后果迫在眉睫：

如果我需要计划下一次冲刺，我需要知道他们将缺席多长时间，因此我需要期待他们缺席多长时间。

你估计他们的缺席，但如果这个估计很糟糕，你就不会发出危险信号。这是一个优先次序的问题。如果公司说演示/演示优先于开发，那么演示/演示所造成的任何合理的缺勤都会破坏sprint计划。

你无法避免这一点。但是公司也不能因为不准确的冲刺而责怪你，因为他们自己同意演示/演示优先。

实际上，这与开发人员因病假而缺勤，或者您的部门因办公室火灾而未能按时完成工作没有什么不同。现实优先于你认为会发生的事情。你无法避免这一点。根据语义定义，您不能期望unexpected__。

Answer 2

会议可能不应该被估计，但是为筹备和进行会议所做的工作应该是。为新用户设计演示并不能使软件变得更好，但它确实有一个有意义的输出:演示设计。会议准备也可以有像文档这样的工件。其中一些可能是开销，但需要为业务完成的工作是工作。

我建议在下一次回顾展上与团队讨论，试一试或两次冲刺，然后重新评估。如果成功了，那就成功了！如果不是，你和团队都应该更好地理解为什么这是个坏主意。

Answer 3

我不认为这是可以预测的，但可能会被发现。

首先，获得不包括准备演示文稿的冲刺的平均速度。这是你的底线。接下来，找到完成这项准备工作的冲刺，并记录下平均速度。减去这两个，你就会大致知道这个作品的故事点价值是什么。

看一看每个人做准备工作的每一个短跑，并记录下与正常速度的差异。希望您能够识别正在准备的确切演示。冲刺速度的差异可以通过为演示做准备来“弥补”。

一些具体的数字。

三次冲刺没有准备工作，你的团队平均得到68分。其他三个完成准备工作的冲刺项目平均得分为62个百分点。它开始看起来像这个准备工作是大约6个点的努力为团队，所以我会把它的整数达到一个标准的8层。

接下来，看一看特定的sprint。假设一个开发者正在为一个新的客户端准备一个演示。这支冲刺队提供了58个故事点，与正常速度相差10分。继续往前走，最多13分。

这意味着，如果您需要在任何给定的sprint中向新客户端演示应用程序，则需要将其与之进行比较。然后只需做以下一件事：

1. 为演示添加一个13点的故事
2. 承诺减少13点

选择一个让项目管理远离你的选择。