使用敏捷电子表格进行发现估计

本文包含一个预先格式化的电子表格，可帮助您开发敏捷发现估计。 它还包括帮助您遵循特色示例的信息。 您可以从此处的模板制作可编辑的副本（文件>制作副本或文件>下载）。

在我组建团队或了解 MVP 要求之前，客户经常要求我提供敏捷估算。 在这个早期阶段，我无法使用速度、冲刺数量或团队成本等传统指标来计算这些估计值。 但客户想要答案。 他们能在两个月或六个月内推出一个假设的产品吗？ 他们的（通常很低的）预算是否可行？

输入敏捷电子表格。

电子表格是敏捷思维方式的合适选择，但经常被忽视。 它们是鼓励协作的低技术、高接触工具。 也就是说，只要产品的成本和质量满足他们的要求，您的客户可能并不关心您的工具是否“敏捷批准”。 电子表格的真正价值在于它们对所有经验水平的项目经理和利益相关者的可访问性。

许多专业项目管理工具的学习曲线对于快速移动项目的没有经验的用户来说过于陡峭。 因此，客户、产品所有者和开发人员更新需求和劳动力成本越容易，您就越早得出现实的估计。 使用预先格式化的电子表格，项目经理可以调整值和参数​​，以展示每个波动资源或移动时间线的影响。

电子表格也是与同事分享知识的好方法。 我使用的电子表格源自 Toptal 的一位同事，此后我制作了一份副本并对其进行了修改以满足我的需要。 我鼓励你也这样做。

在本文中，我将演示如何提供成功的发现估计，使客户和利益相关者能够与项目目标保持一致并继续开发。 以下是如何填补空白并提供您可以支持的早期估算。

首先解决产品愿景和路线图

假设您的客户想以固定预算开发一个约会网站，但产品的细节却很模糊。 在不了解团队成本和速度的情况下，产品愿景是最好的起点，因为它需要利益相关者就设计目标达成一致并提高整个团队的透明度。

我喜欢 Scrum.org 产品愿景格式的直观叙述风格。 这是它的样子：

设定产品愿景后，您可以在新的电子表格选项卡中添加产品路线图，让客户了解长期项目计划。 路线图应列出每个产品路线图版本的目标、关键特性和截止日期。

路线图版本是指导其市场轨迹的产品的计划、面向消费者或客户的版本。 第一个路线图版本是您可以在市场上首次亮相的产品。 随后的路线图版本代表具有与产品愿景一致的引人注目的新功能的市场版本。

以微软为例：Windows 8 可能是一个路线图版本。 Windows 10 是另一个路线图版本，具有许多新的和理想的功能。

一旦产品愿景和路线图完成，就该要求客户承诺 MVP。

使用三重约束图协商 MVP 功能

现在是使用三重约束图表来塑造客户对时间和费用的期望的时刻：

在瀑布方法中，固定功能决定了时间和成本，并且根据详细的项目计划进行开发。 相反，敏捷的固定成本和进度决定了产品的功能，并且这些功能会根据更灵活的项目愿景不断地重新排列优先级。

三重约束图表向客户表明，在第一个版本中包含所有所需的功能将增加开发时间和气球成本。 取而代之的是，与客户一起为 MVP 选择“必须具备”的功能，并列出任何剩余的功能以供将来发布。

电子表格可以根据客户的不断变化的需求，轻松地将功能分组和重新分配到不同的版本、版本和优先级，并且它们会立即显示这些更改的成本。

在您确定 MVP 功能时，请向您的主题专家 (SME) 寻求帮助，根据他们从事的类似项目列出项目的步骤。 稍后您将使用这些步骤来创建史诗。 一旦你准备好这些输入，你就可以开始建立一个估计。

从 T 恤尺码开始

要开始第一个积压工作，请向产品所有者询问产品功能的详细描述，然后根据每个功能的难度级别为其分配 T 恤尺寸。

在您获得任何绝对值之前，T 恤尺寸将显示每个开发任务的相对复杂性和持续时间。 随着我们对项目计划的深入了解，我们会将这些相对大小转换为故事点和工作时间。

例如，如果您的客户希望您在约会网站上开发一系列弹出窗口，那将是耗时但简单的。 您可能会将任务复杂性描述为“小”，但工作量将是“中”。 您可以将其缩写为“SM”。 另一方面，由于所有必需的文档和测试，为新 API 开发后端连接将是一项更复杂的任务。 为此所需的技能和注意力可能使其在努力和技能水平上都成为“大”：“LL”。

完成 T 恤尺寸调整后，您将对每个未来团队成员的相对工作量和技能要求有所了解。 然后，开发团队的技术专家可以帮助您将 T 恤尺码与时间范围和故事点相关联。

设置你的参数

现在您已准备好使用电子表格并计算您的估算值。 首先创建一个参数选项卡。 这将作为您计算的关键，您在此处输入的值将输入到您的待办事项/用户故事和按发布选项卡估算摘要中使用的公式。

这是您在“参数”选项卡中需要的所有内容：

货币。 这是您输入货币换算的地方。 例如，如果客户的预算是巴西雷亚尔，您可以输入美元或欧元的当前兑换率。

开始日期。 预计开发开始日期将用于创建项目时间表。 在每个示例中，我们的开始日期都是 10 月 25 日。

初始预算。 预算提供了约束，显示是否所有 MVP 功能都适合它。

T 恤尺码。 以表格形式输入您的 T 恤尺码，并为每个尺码组合分配故事点和小时范围。 在此示例中，SS 使用 1 到 2 小时，LL 使用 33 到 48 小时。

请记住，您的冲刺持续时间将限制您最大 T 恤尺寸的小时数。 如果冲刺只有一周，最大的规模不能超过 40 小时。 这就是为什么在为任务分配 T 恤尺寸时咨询 SME 如此重要的原因。

每小时费率。 使用此表记录每个角色的工资率。 如果您的后端开发人员有不同的费率，请使用两者的平均值。

高架。 将项目总工作量的一部分分配给管理任务，例如状态会议、反馈会议和项目修订。 百分之十（或每个参与者每周工作的四个小时）是一个很好的起点，但对于更复杂的项目，开销可能会更高。

意外情况。 这表明您的估计中的潜在差异。 考虑到您在电子表格中输入的值，从 0% 的意外事件开始将向您显示最佳情况（即不太可能）的预算和时间表。 稍后在我们的示例中，我们会将意外事件增加到 50% 的粗略数量级 (ROM) 方差，以显示成本和项目持续时间的潜在高端。 随着您获得更精确的数字，意外事件将减少。

每个版本的大小与史诗

我们从整个产品的粗略尺寸开始，以确保我们不会浪费客户的时间或金钱。 根据规模与他们提出的预算和截止日期的接近程度，客户可能会决定放弃该项目或投资于更详细的估算。 因为此时我们没有太多细节，所以我们在 Backlog/User Stories 选项卡中输入主要功能作为史诗。 然后，对于每个史诗，我们输入 SME 和开发负责人根据“参数”选项卡中的 T 恤尺寸表为每个开发堆栈建议的小时数。

首先，选择“EPIC？”列并确保只选择了“史诗”。

接下来，写下史诗描述并输入开发堆栈每一列的小时数。 例如史诗级的《安全连接和登录》大约需要 8 个小时的 UI 开发，40 个小时用于后端，等等。

请注意，在大多数情况下，“点”列中的单元格显示“34*”。 如果返回“参数”选项卡，您将看到 34 个点对应于 33 到 48 小时之间的每小时范围。 如果我们的 sprint 持续时间只有一周，那么这个小时数就太长了。

一旦我们有了更多细节，这些时间就需要缩短，或者史诗必须分成更易于管理的故事。 然而，为了时间的缘故，我们将忽略点列并继续粗略估计。

现在转到 Estimate Summary by Release 选项卡。 在电子表格的顶部，您将看到“参数”选项卡中定义的“开销”和“应急”值。 您还可以选择一个按钮来按史诗或用户故事显示估算值。

因为我们还没有要显示的用户故事，所以请选中“史诗模式”按钮。

您现在可以看到 MVP 的粗略成本和时间表，以及未来版本（R3 和 R4）中不太紧急的功能和更新。 在此示例中，第二个版本 (R2) 为空，因为客户已要求在第一个版本中启动所有 MVP 史诗。

您现在可以看到最乐观的总成本：28,810 美元。 这个数字是从 MVP 到 R4 的每个版本的成本总和。

我们还估计了产品交付的最短时间线，这对应于 R4 开发堆栈中的最新完成日期。 项目经理将这些较慢的开发堆栈称为“关键路径”，因为它们决定了整个发布的速度。

在这种情况下，关键路径是前端开发，完成日期为 1 月 31 日。

现在是时候调整参数以模拟最坏情况的预算和最长的时间线了。

将应急率调整为 50%

我们仍然对产品的工作量和专业知识要求知之甚少，因此我们将在“参数”选项卡中添加 50% 的 ROM 意外事件。 随着我们了解有关该项目的更多细节，意外事件将减少。

同样，这里是 0% 意外事件的总项目估算。

这里是 50% 的意外事件。

这意味着整个项目的 ROM 估计在 28,810 美元到 41,860 美元之间。 在最好和最坏的情况下，客户的 20,000 美元预算不足以包括他们愿望清单上的所有功能。

50% 意外事件的完整项目完成日期现在是 3 月 14 日，比 0% 意外事件完成日期晚了六周。

与此同时，MVP 将于 1 月 10 日准备就绪。

客户并没有放弃该项目，而是要求进行更详细的估算，看看它是否可能在更短的时间内更接近他们的目标预算。

重新确定满足最后期限的优先顺序

假设客户将 MVP 的目标日期设置为 12 月 25 日，距离 10 月 25 日启动还有两个月。

为了提前 1 月 10 日的 MVP 完成日期，客户同意将两个 MVP 史诗推迟到下一个版本 (R2)。

电子表格计算此调整的级联效应。 在这种情况下，MVP 时间线缩短到 12 月 27 日。前端和后端开发是本次模拟的关键路径，因为它们需要最长的时间才能完成。

根据此信息，您可能决定再添加两名开发人员，以使前端和后端的完成日期与其他开发堆栈保持一致。 为此，请将 MVP“每周工作时间”行中的工作时间从 40 增加到 80。

前端和后端开发堆栈现在都在 11 月完成，QA 成为新的关键路径（完成日期为 12 月 20 日）。 请注意，成本不会改变。 这是因为每个堆栈中的总工作时间保持不变。 不是一名开发人员工作两周（80 小时），而是两名开发人员工作一周（80 小时）。

该电子表格还考虑了全职和兼职工作之间的差异。 假设 UI 开发人员将兼职工作。 我们可以将 UI“每周设计小时数”更改为 20 以模拟交付延迟。

按照全时计划，UX/UI 将于 11 月 29 日完成。

在兼职计划中，UX/UI 将于 12 月 27 日完成。

再一次，成本没有改变，但 UX/UI 成为新的关键路径，将 MVP 的时间表延长到 12 月 27 日。

您可以继续这种反复试验的方法，直到根据您的资源和客户的最后期限到达可接受的关键路径。 一旦适当的截止日期到位，就该开始微调您的估算了。

使用用户故事优化您的估算

由于 50% 的意外事件估算超出了客户的预算，因此值得细化您的变量，以便您可以降低意外事件并获得更现实的估算。

为此，请与您的开发人员和 SME 合作，将您的史诗分解为详细的用户故事。 故事比史诗定义得更好，因此我们可以更准确地确定它们的大小。

接下来，根据任何新信息调整参数选项卡中的值。 例如，您的 SME 和开发团队可能对每个角色有一组更准确的费率，并且可能还希望调整 T 恤尺寸和积分分配。 有了这些新参数，您可以对自己的计算更有信心，并将意外事件降低到 25%。

让我们看看我们如何将史诗分解成更小、更详细的用户故事：

与需要手动输入每个堆栈的估计小时数的史诗估算不同，故事估算使用 T 恤尺码作为快捷方式。 这就是您在“参数”选项卡中输入的 T 恤尺寸派上用场的地方。

在 Backlog/User Stories 选项卡中的“T-shirt Sizing”下，输入您的开发人员和 SME 为每个故事分配给他们的堆栈的尺寸组合。 从那里，电子表格公式将自动填充“参数”选项卡中的相应小时数。 请记住，最大尺寸 LL 必须保持在 34 点以下，以确保它可以在您商定的 sprint 持续时间内完成。 任何仍然评分为 34 分或更高的故事都需要细分。

确保为所有故事分配的点数少于 34 点后，取消选中 Estimate Summary by Release 选项卡上的“史诗模式”按钮，以便仅查看“故事”。

现在你会看到一组新的数字：

在详细说明所有任务并仅坚持 MVP 功能之后，时间线和成本现在符合客户的要求。 由于余额完全在他们的预算之内，客户决定继续使用 MVP 并在提交其他版本之前对其进行测试。

让它成为你的

电子表格易于使用，并且具有一些基本的公式知识（不需要宏），您可以调整它们以适应几乎任何需要。 如果您的 Excel 知识生疏，Udemy 和 edX 的在线课程将帮助您重温这些技能。

本文介绍了发现估计，但您可以使用相同的电子表格来生成燃尽图/燃尽图、调整时间线并根据速度和冲刺计算估计以供后续阶段使用。 我使用我的自定义电子表格来补充应用程序，例如 Jira、Asana 和 Trello，并坚持认为它们是我的项目管理工具包中的强大工具。 我希望它们对您同样有用且用途广泛。

与现成的项目管理工具相比，您更喜欢自定义电子表格吗？ 在评论中告诉我们为什么或为什么不。