敏捷估算指导
敏捷评估是一个容易理解的概念，但是当橡胶遇到道路和遗留工件(如LOE(工作级别)、使用报告和其他工件)时，问题就出现了。比如，“我们应该以小时为单位进行评估吗?”以及“我如何将t恤尺寸转换为点数?””出现。对于一个组织来说，找到一种通用的评估方法是很重要的，特别是当我们将治理模型从团队到程序再到投资组合的时候。
有许多研究表明，估计在短期内是有效的，但在长期内是不可靠的。此外，在审查任何价值流(如软件交付生命周期)时，利用率要让位于吞吐量。
我不打算深入讨论敏捷评估的许多类型。然而，我将为我和我的同事在领导敏捷时提供指导和标准。
史诗估计
史诗是粗粒度的项目，我们希望将其构建到产品或流程中。我更喜欢史诗级的作品，但它们可以跨越不同的版本。史诗应该在一个月到三个月的时间范围内。Epics的t恤尺寸如下:
S - 1冲刺[1]
M - 2到4个冲刺
L - 5到6次短跑
如果超过6个sprint，史诗就应该被分解
[1]持续2周的冲刺或迭代
功能评估
特性适合于一个版本。(我们得计划一次发布会。)为了做充分的发布计划，我们使用了map。这些特性的大小和优先级决定了它们在我们sprint中的布局。应该估计特征以周为单位，所以我建议一周到五周的时间框架。
避免在功能上使用点。一旦用户描述被分解并应用了描述点，就可以将描述点卷到功能层。因此，当团队完成特性中的用户故事时，这将为您提供最真实的“特性完成率”。
如果你有一个经验丰富的团队，并且有很多可参考的故事，那么在特性级别使用故事点是可以接受的。如果是这种情况，我建议您在用户描述刷新时更新这些点。
用户故事估计
用户故事在它们长成一到三天的大小之前，应该把它们分解。新团队可能很难做到这一点，但产品负责人团队和交付团队的目标应该是朝着这个目标努力。
因此，故事点应该用来评估故事。
新的敏捷团队
作为sprint计划的一部分，新团队应该执行任务分解。在sprint计划中，每个故事被分解成需要执行的任务;数据库更新、java接口需要更新、单元级测试更新等。这些任务是以小时为单位分配的。
每个任务都应该保持在8个小时以内，这样我们每天都可以看到一个更流畅的冲刺过程。任何更大的东西都不能为团队提供可见性。进行任务时间分解的团队将使用一个小时的sprint burndown。没有将任务分解成小时的团队会使用故事点冲刺burndown。一些工具供应商可能只支持每个工具实例的burndown的一个版本。因此，在确定团队将如何管理其sprint之前，应该对这一点进行调查。
评论(4)
阿米尔
您可能会发现基于sprint而不是基于周的分级功能也很有用。特别地，如果你的冲刺时间不超过两周，并且你正在使用视觉板进行特性测试。
亚历克斯Kanaan
好崩溃。团队经常在用户故事级别进行评估，但没有足够的注意向上评估——有趣的是，还看到t恤尺寸应用在史诗级别。让我们记住的终极目标是提供价值或tested-working软件终端客户,所以我也建议有一个明确的“完成”的定义,反映了这一承诺,我也经常看到团队专注于评估开发工作但不包括其他工作的一部分如任何研究或估计为待办事项列表、各种测试活动(包括PO验收测试)、集成、部署等增加清晰度的对话。
马蒂·布拉德利
我同意明确“完成”的定义。这涉及到共享理解的整个概念，这是构建正确解决方案和帮助实现可预测性的关键。史诗级别的t恤尺寸是一个很好的方法，可以知道你是否有真正的史诗或它们实际上是倡议。最好的办法是把这些史诗分解成业务能够提供真正的价值。亚博vip9通道如果你能赋予真正的价值;延迟成本、内部回报率等都非常小，因此更容易进行双月或季度预算审查/路线图调整，以始终关注业务的最高价值。亚博vip9通道
的同时
嗨,马丁,
这看起来太棒了! !这是如何影响sprint消耗图表的呢?你能提供一幅地图，显示出工作时间加起来是如何影响t恤尺寸的吗
问候,
的同时