我知道，在你的 sprint 计划的第一部分，你会使用故事点和扑克牌来调整故事的大小，然后你估计下一个 sprint 可以处理多少个故事。因此，假设您同意处理 3 个故事，总共 18 个故事点。
然后您继续进行 sprint 计划的第二部分，并开始将这些故事分解为任务。这些任务现在是使用实际小时数估算的。
我有两个问题：
1）您如何以小时为单位估算任务？您是否再次使用扑克估算但这次有几个小时？团队如何就每项任务的小时数达成一致。
2) 一旦你估计了你同意的 sprint 的 3 个故事的所有任务，你会发现所有 3 个故事的所有任务的总小时数是 90 小时。如果您的实际团队容量（以小时计）为 75 小时，那么既然您意识到自己实际上没有时间去做，那么您如何调整交付 3 个故事的初始承诺？你是否会回到你的产品负责人那里（如果他不在了）并告诉他们你将提供 2 个故事，或者你将如何处理？
非常感谢您的帮助！
这些任务并不是真正以小时为单位估计的，而是以理想时间为单位的。很难预测一周内有多少理想的可用小时数，而且根据小时数估算来推断 sprint 的容量通常根本不是一个好主意。例如，请参阅这篇Scrum 联盟博客文章
故事点数和任务时数的比较可以看作是一头大象的体重和身高的比较。一般来说，较高的大象可能比较短的大象更重，但情况并非总是如此。尽管普遍认为更高的身高意味着更多的体重，但没有体重与身高公式的生物学证据。同样的解释也适用于故事点与任务时间：一般来说，更复杂的用户故事（更高的点）应该需要更多的时间来完成，但总会有例外。
通常，任务由单个团队成员（或一对）处理，因此它们是由他们估计的，而不是由整个团队估计的。
此外，每天都会重新估算任务：我们寻找的数字是完成任务的理想小时数，而不是总数。因此，它是一个可以上升或下降或保持不变的数字。
此外，可以在 sprint 期间添加或删除任务。发现初始计划发生变化实际上很常见。没关系，只要计划的总小时数代表当前对剩余工作的最佳估计 - 燃尽图需要它。
总之，不要介意时间。使用它们来监控 sprint 期间的进度，但不能确定容量。这就是积分的用途，这两个参数不能像看起来那样互换。
根据我的经验，闯入和评估任务非常有用，而且经常被低估。这个想法是，随着时间的推移，团队在他们的冲刺中变得越来越准确，他们检查和适应。我观察到团队最终会完成冲刺中的所有事情，除了不可预见的阻碍（例如服务器停机时间）。这个想法是团队以（小时）计算他们的能力，然后计算他们需要完成的任务量（以小时为单位）。他们可以以此为指导做出承诺。这里有更详细的解释：http: //www.pashunconsulting.co.uk/team_commitment_blog.html
您也可以使用故事点做出承诺，但一般原则是故事点更适合长期估算（即估算项目何时交付）。Agile Estimating and Planning 是一本关于这类内容的好书，Scrum Mega Pack 也是如此。
我想一个问题来自假设您能够在 sprint 中交付 18 分。当您在数小时后进行估算时，看起来不对劲的地方。因此，最初承诺较少数量的故事点，在几个冲刺之后，您将能够知道每个冲刺的故事点的实际速度。
虽然将故事分解为任务很有帮助，但估计这些任务并不是很有用。原因是您将花费大量时间进行这些微观估计，而且它们通常是不准确的。
此外，添加具体的每小时估算会迫使工作适应这些估算。如果你低估了你可能会拖延，如果你高估了你可能会跳过评论、单元测试或其他质量实践来适应时间表。
所以总的来说，我喜欢保持一个估计水平 -> 给出速度的那个。