团队正在评估故事点，业务需要实际时间

我敢肯定这不是一个罕见的主题。我们有两个Scrum团队可以很好地使用故事点来估计用户故事（当前团队的星座只有大约8个月大，尽管团队成员具有几年的Scrum经验）。但是，对于公司的业务部门而言，很难与用户故事相关联。他们想要实际的时间单位（或“将故事点转换为小时数的公式”），以便他们可以为何时准备就绪制定计划（“我们需要知道何时可以告诉客户Feature X即将投入生产”。

我和我的Scrum大师的前任当然已经解释说：“故事点和实际时间之间没有明确的关系”，并且“故事点用于确定团队适合冲刺的程度”，我确保您可以猜出他们对该答案的满意程度。他们仍然想在日历时间内知道何时获得积压的第27个用户案例。

无论如何，我一直在编辑一些统计数据，我们的SP估计值转化为实际花费的时间差异很大（由我们的Scrum Board软件衡量，该软件可以跟踪“在”列中花费的时间） ）。对于1-SP用户故事，当然会非常倾向于很短的时间跨度（偶尔会出现爆炸），但是特别是对于2-SP用户故事，它们无处不在：大约有20倍在“最快”和“最慢”完成之间。对于3、5和8-SP故事，传播也超过2倍。

这表明（a）团队需要在估计相似程度（应该是）的用户故事方面更加一致，并且（b）团队需要提高时间报告的准确性（即记住将票证移出当他们在会议上，午餐时或打足球时进行“锻炼”。

我已经计划改善（a）和（b），但是我觉得这还远远不够，因为企业期望比这些计划产生的结果更“具体”。

有什么好的策略可以使业务方面愉悦，从而使它们不会对我们的工作产生太大干扰（例如，通过使用单独的时间跟踪，恕我直言，这是愚蠢的，因为在任何情况下它的准确性都不如当前的“自动”跟踪），同时又让他们获得一些具体的度量标准来确定故事何时完成？

（从历史上看，在规划过程中，我们确实将用户故事分解为工作项目，然后在实际工作时间中分别进行估算，但是我在这里要说的是备用日志中的用户故事，而这些细节或详细程度不会-下。）

更新：我的经理有一种预感，即每个故事点花费的小时数呈钟形分布，但我整理的数据和他制作的图表使他完全没有这个想法。:-)

您是正确的，没有公式可以将故事点转换为小时。您可以得到米到英尺的无损转换，反之亦然，但是您不能说三分的故事将花费X个小时，所以五分的故事将花费Y小时（求解Y）。

HorusKol谈到了下一部分。作为一个团队，您的冲刺速度可以帮助解决长期交付的问题。假设您的团队每个冲刺得分为50分，每个冲刺为2周。因此，每冲刺50分乘以一年中的50周（假设人们休假2周），那么您当前的团队在12个月内最多可​​以得到2500分。

因此，您可以获得价值170点的故事和史诗般的业务。将其除以团队的历史速度50点（到目前为止，每个冲刺的平均值），即可得到3.4个冲刺。由于我们正在估算，因此最多四次冲刺：八周。基本上两个月。我也喜欢最后3-4个冲刺，并进行另一个估算。假设您的团队在最近3个冲刺中分别取得了53分，67分和55分。这样算来可以达到58 ish点，按照这个速度是2.9冲刺-基本上是3冲刺。看起来您的170个时间表的时间表看起来像是6到8周。

告诉企业2个月。不要告诉他们6-8个星期，因为他们只会听到“ 6个星期”。甚至不要告诉他们8个星期，因为大多数月份中有大约4.5个星期，而当人们听到“ 4个星期”时，他们会立即认为“ 1个月”。一旦估计达到约4周，它将变为1个月。然后只需几个月。如果您打了一年或更长时间，那么说实话就不要估计这项工作。这是毫无意义。一年内可能会有太多变化。

我发现这是将故事点转换为小时数的一种相当准确的方法……好吧，无论如何。

您将花费不同的时间来完成各个故事。一些开发人员的工作速度比其他开发人员快。将所有故事点放入碗中，然后打开搅拌器以使用平均值进行处理，可以减轻这些不一致之处。

哦，别忘了最重要的部分：

围捕。总是。

您可能已经从故事点到时间估计已经进行了一些固有的转换-如何确定已为冲刺选择了足够的作品？您可能已经说过类似的话：“团队每周可以处理20分（或40分或其他）”。经过几次冲刺后，您应该能够根据完成情况对其进行修改-现在是15或25（或35或50或...）点，这是团队的速度。

对于1-SP用户故事，当然会非常倾向于很短的时间跨度（偶尔会出现爆炸），但是特别是对于2-SP用户故事，它们无处不在：大约有20倍在“最快”和“最慢”完成之间。对于3、5和8-SP故事，传播率也超过2倍。

在点值内，完成特定故事的时间会有一些变化-速度是最近历史的平均值，可以照顾不确定性。

但是，您可能需要认真研究一下如何分配点，特别是如果您获得如此大的波动时，尤其是那些两点指针。较高点的任务应该是不确定的（应该分解）-但是只有2指针的任务应该是相当一致的。

由于所有分配了相同点值的任务都需要类似的工作，因此完成如此多的时间范围是没有意义的。

因此，请查看回顾中花费时间最长的2指针。为什么应该将一个早晨应该采取的措施变成了10天的停滞期？在第一天早上是否可以标记出一些东西说“这需要变得史诗般的并且分解成较小的任务”？当然，一旦发生这种情况，就应该将所需的额外工作放入待办事项中，并且不要干扰其余的sprint。

另外，请尝试查看团队如何低估了该项目-您能否在审查该项目的未来项目上做得更好？

是的，将相应地推迟交货日期，或者可以修改更新功能列表，以使交货不受影响。但目的是改善未来的点估计，并获得更准确的时间表。

就像天气预报：距离越远，可靠性越低。这是每个人都会理解的类比。估计误差加起来。

销售人员必须学会用Scrum术语与客户交谈。Scrum没有孤立的意义，它应该在整个公司中垂直应用，并且最好扩展到客户领域。

您作为开发团队应该对此坚定不移。您可以给他们期望和猜测，但不要将其作为延伸单个冲刺的承诺。

当我遇到这样的问题时，我会做一些事情。

首先，我通过描述过去来回答关于未来的问题。我会说类似“ 我们每周讲完大约两个故事”的内容。因此，如果没有任何变化，我们预计将在大约14周内完成故事27。

其次，我希望面对客户的客户对交易时间表与风险负责。我会说类似“ 记住”的内容，工程团队的工作是基于50/50的估算。如果没有任何变化，则功能27在14周内准备就绪的可能性为50/50。大概您不想向客户报告具有这种风险级别的风险。您是否要我估算出我们有90％的信心？然后，您需要查看历史证据并说出类似的话：故事27将在25周内完成的可能性高达90％。

最后，提醒您的同事，一旦他做出外部承诺，公司就会被固定下来。对故事编号27做出外部承诺将丧失公司的所有敏捷性。然后，您将致力于采取特定的措施。每当有人提出变更请求时，您现在都需要回答。我们已承诺在x日期之前完成故事27。只有您与客户联系并告诉他们我们的承诺不再有效时，我才能进行此更改。基本上，对未来一个多月左右的工作做出具体承诺会带来很多问题。

您已经有一个（非常粗糙的）转换：（
通常）两周的Scrum冲刺。
您知道您可以在这两个星期内完成大约20个故事点的功能（或者您如何确定一个冲刺中包含哪些功能和多少个冲刺？），而您之前的冲刺可以确认这一估算值（比如说您在最近5个冲刺中完成了18、21、23、19和20个故事点的功能，就算完成了）​​。

假设特征X（及其所有依赖项）估计为47个故事点。
因此，您可以估计，如果您将实施此优先级设置为最高，则应该花大约3个冲刺，即6周（但请确保您的估计考虑到了谁可以做的事情-如果其中35点是数据库工作，而您只有对于数据库专家，您需要修改您的估算速度以将其考虑在内）。

话虽这么说-坚信这些是粗略的估计-冲刺是两周而不是六周是有原因的。您的预测需要涵盖的内容越多，不确定性和错误就会越多。还要牢牢地传达成本-即，这意味着将任务放在首位，这意味着其他任务无法进行。否则，您可能会遇到以下情况：

“功能Y何时完成？”
“如果我们接下来专注于此……12周”
“ 12周？！？您说需要4 周。 ”
“是的，但是您告诉我们要优先处理功能X，我们告诉您将绑定所有资源并花费8周的时间。”
“您不能同时使用功能X和功能Y吗？”
“ 呻吟 ”

冲刺是定义的时间，例如2周。您无法预测某些故事会比2个冲刺更进一步，例如您拥有当前的冲刺和下一个冲刺。我假设您已准备好与团队讨论以供下次冲刺的故事，并且已按业务进行了优先排序。因此，您最好可以肯定地说接下来的四个星期是工作。

超过4周的所有内容都可能发生变化，并且业务可以制定未在数小时内确定的路线图。这应该按每个sprint计划，比如说一些epic1（如在成组的故事中的基拉故事）和epic2应该在sprint 47和48中完成，而epic3应该在sprint 49中完成。看看一个或两个是否适合冲刺，无论如何时间线都会滑落。如果功能不起作用，则企业必须缩减范围或接受不完善的解决方案，这些解决方案可以在以后根据需要进行改进（应该敏捷，接受现实而不是遵循计划）。

您可以使用未来的冲刺和主要主题/史诗来制作精美的甘特图（这是企业所喜欢的）。

我喜欢每个Sprint都发布，然后准备Sprint中完成的发布（或者即使不是完美的，也要由企业签署以供发布的内容），未完成的内容将进入下一个Sprint。这样，我可以在2-3周左右的时间范围内实现可预测的交付（对于发布候选版本的最终修复，一个星期）。

这就是我在小团队，少量外部依赖以及我认为合理的业务方面的经验。您的里程可能会有所不同。

对于新功能，几乎不可能估计所需的时间。

软件开发的经验表明，在大多数情况下，有些细节在真正开始开发之前就看不到。在最好的情况下，这些处理可能需要一些额外的时间，但在最坏的情况下，该项目也会失败。其原因是软件开发本身的复杂性。

这就是为什么SCRUM仅估计问题的复杂性（故事点）而不是时间的原因。您唯一的机会就是将复杂度高的功能拆分为较小的功能。这样您可以将风险降到最低。

由于时间估计几乎是不可能的，因此没有公式可以将故事点转换为时间估计。速度只能是非常粗略的估计，而不能更多。

在SCRUM中，产品所有者可以在每次冲刺之前更改积压项目的优先级。因此，SCRUM主控程序不能给出超过一个冲刺的任何估计。他不知道哪个积压项目在下一个冲刺中可能变得很重要。

SCRUM并不是一种处理不可能完成的事情（计划不可计划的事情）或使开发更快的方法。如果开发用完了，这是一个预警系统。它允许对新要求做出快速反应。

到最初的帖子：

如果您能够将大多数任务拆分为1个SP到5个SP故事，那么您已经非常出色。如果任务相似并且您的团队经验更丰富，则速度估算可能会更好。但是，如果新项目中总是有新的，未知的零件，则您必须忍受不准确的情况。

由于您的开发人员通常会花一些时间进行非开发工作（例如会议），因此您不应计划每天进行8个小时的开发，而应减少例如6个小时的时间。这样一来，您就可以为其他任务或工作项目预留更多的时间。

如果您的业务同事想要准确的估算（这本身就是一个矛盾），请向他们解释软件开发的固有问题。然后向他们展示敏捷方法的优势。