确定敏捷团队可以完成多少任务小时
我想欢迎Jim Magers加入敏捷领导团队。吉姆和我一起在明尼阿波利斯做一个项目，我邀请他来和我一起分享他在这个领域的一些经验。
您的团队对敏捷还不熟悉。
到目前为止，您已经梳理和组织了您的backlog，定义了您的史诗和特性，并编写了一些用户场景。你对你的接受标准的质量和定义非常满意。团队已经对故事进行了分级，您已经将一些故事分解为任务，并为它们分配了理想的时间估算。那么，你怎么知道团队可以花多少小时来完成一个成功的冲刺呢?
我指导过的团队都发现了这个sprint利用工作表成为估算初始团队能力的有用工具，大多数人继续使用它超出其敏捷发展的早期阶段，因为他们继续调整并改善他们的初始假设。
请记住，理想的一小时是一小时的工作，其中一个人能够完全关注没有中断。我的经验是，一个平均整体利用率为65％的敏捷团队通常效率高效。这意味着，在8小时的一天中，利用率为65％的团队成员正在完成每天5到6个小时的努力的某处。但你可能有比这更高效的团队成员。也许他们可以远程工作，不要被拉入尽可能多的会议或侧面问题，因此更能在Sprint工作中更好地关注更好。
在翻盖方面，还有其他人甚至不接近击中65％的目标。这些可能是尚未完全培训的新员工，或者可能是他们经常被拒绝与客户或生产问题进行处理。
当然，人们会有假期和预定假期。所有这些都需要考虑进去，以便能够自信地估计理想的小时容量。
此工作表假设为两个星期的冲刺，或者为每个团队成员提供80小时的理想启动时间。对每个团队成员的利用率进行最好的初步猜测，尽可能真实地了解他们关注即将到来的sprint的团队工作的能力。在工作表示例中，我分配的利用率从Pete Hill的25%到Mary Doe的80%不等。
如果你知道员工根本无法完成“冲刺”任务，就不要把时间花在计划好的假期、假期或全天会议上。Joe Smith, Tom Jones和Brenda South都在我们的迭代期间休假了，这反映在“预期非工作时间”一栏中。
然后将我们留下了理想的时间，并且在应用个人利用率之后，我们可以为每个团队成员推导出理想的小时容量，总结为计算Sprint可用的总潜在团队时间。
虽然该组在Sprint中有408个理想的时间，但基于这些因素的利用和时间远离冲刺的真实工作，队伍应该可以采取大约229个理想的任务。
如果您的团队足够成熟，已经建立了一致的故事点速度，那么这个工作表还会让您了解在即将到来的sprint中可以处理多少故事点，基于相对于历史容量的某种程度的增减。在我的例子中，离开办公室的时间减少了15%的团队潜力。由于团队全速运行时的平均开发速度是35个故事点，减少15%将导致推荐比通常情况下少接受5个故事点。
评论（12）
戴夫鲁尼
你好吉姆，
当团队已经完成了2-4个sprint之后，有什么能阻止他们使用昨天的天气来确定在sprint中需要准备多少待办事项?换句话说，如果他们在前一个冲刺中完成了20个点，那么在当前冲刺中只承诺20个点。
毕竟，完成积压项目是将值为产品所有者提供的值，而不是完成任务。团队可能会挂断任务，并进入近85％的任务的不幸位置在Sprint的尽头附近完成，但不是一个完整的积压项目。
我的经验是，随着时间的推移，慢慢地把注意力从任务中移开，直接放在待定项上会更有效。
嘿,大卫,
我同意交付待定项是有价值的。但根据我的经验，没有速度记录的新团队真的可以从将这些待办事项分解成更细粒度的任务中获益，并且能够满怀信心地进入冲刺阶段，相信他们能够完成他们所承诺的工作。我看到这个工具帮助他们实现了这一点，成功孕育了成功。我刚开始工作的一个团队声称自己已经敏捷了近一年，但从未成功完成过一次sprint。这个工具被证明是有用的，可以帮助他们计算出适当的工作量来承担和完成。一旦他们掌握了航海技巧，他们就不需要那么依赖这个了。
因为大多数开发人员都喜欢逻辑的、分析的方法，所以当我使用这个工作表时，我看到怀疑的新团队成员接受了工作承诺，他们的接受有助于团队的成功。
戴夫鲁尼
嗨,吉姆,
当然，我同意这对一个刚刚起步的团队是有用的。但是，当团队有一些速度数据点时，在2-4个冲刺之后就可以停止训练了。
缩短会议时间也是获得大量支持的一种方式。:)
我一般都认为，2-4冲刺不是正确的指标。正确的指标是当团队擅长瘦身切片的瘦身时。希望这是2-4个冲刺......但并非总是如此。如果一个团队正在使用相对估计，并且一切都落入1或2级...有时3，我通常试图仅使用故事点。当我仍有5,8,13 ......或者上帝禁止，20个在积压项目上......我们正在做任务细分。我必须看到Sprint中的增量交付......我更喜欢增加用户故事的递增......但如果这就是我所拥有的那样，我会采取任务。
此外，吉姆的方法确实解决了一件事，那就是当人们外出时如何处理。如果我们利用昨天的天气，考虑到失踪人员的缺席，团队只能凭直觉来判断他们能做些什么。成熟的团队能很好地处理这一点，但新团队可能不能。所以这可能只是前面论证的一个特例。伟大的谈话!
戴夫鲁尼
嗨,迈克,
我完全同意薄片，并且更喜欢团队只使用1、2、3或“太大”来进行估算。我现在的客户是电信行业的，有合法的1，也有合法的13，尽管这一情况会随着时间的推移而改善。
为了处理缺勤，长期平均速度应适应这一点。如果您有7个人为整个Sprint，那就是另一个故事，但使用平均值应该正常化速度的轻微变化。
我想我的观点可以总结为:“不要想太多!”
布莱恩·桑德迦
吉姆,很好地完成。嘿!我想我认识这个电子表格:-)
乔纳森Warshay
到工作表的链接已死。工作表是否在其他地方可用?谢谢!
刚修正了链接。
书中
我想为每次迭代创建容量规划电子表格。如何使用（Sprint Unitifation Worksheets），这些都是XML文件。你可以帮忙吗？
谢谢
嗨dinesh，
我不太明白你的问题。你提到的xml文件是什么?文章中的链接指向一个Excel文件。
Kirk Bryde.
吉姆，就像基于团队的容量调整每次迭代的想法一样（以小时为单位和％可用性）。我认为重大因素是（a）迭代中有多少工作日 - 由于统计假期，一些迭代将有较少的日子;（b）团队成员的计数 - 随着成员来的，波动（因为成员来）波动;（c）每个团队成员的％可用性 - 全职成员100％，少对段计时;（d）由于假期，疾病，培训，特殊任务等，对每个团队成员的重大缺席 - 到最近的半天。
然而，依我之见，我认为你做得太过了，因为你试图估计一个正常工作日的正常团队成员的可用时间百分比。我想说的是，对于全职团队成员来说，我认为你不需要估计每天有多少时间花在查收邮件、参加公司会议、茶水间聊天或其他耗时的事情上。
速度算法已经解释了所有这些“低效”，所以你不必这么做。也就是说，给定每个团队成员在每次迭代中的平均每日开销，团队的能力是一致的，因此速度也将是一致的。也就是说，你只需要考虑异常——而不是例程的开销。
玛尔塔Zdanevych
你好吉姆，
我真的很喜欢你的表达方式。我必须承认，这就是我领导开发团队时的工作方式。
然而，目前我在一个功能性的办公室工作，最近有人建议以两周的冲刺为基础来规划我们在Jira的工作。我们还建议(要求)在两周内计划大约80小时的任务，并避免在“冲刺”期间发生变化。我们所做的工作依赖于与其他涉众的沟通和会议，并且每个sprint都有一些优先级活动需要与拥挤的时间表相适应。
你有在办公室工作中规划理想/实际工作时间的经验吗?
提前两周计划什么时间比较合适?
如果我们不度量速度和能力(我们不度量是因为每个人都在自己的范围内工作，根据自己的估计)，那么如果我在sprint期间改变计划中的任务，那又有什么区别呢?
你建议在办公室工作中衡量什么?
多谢
玛尔塔