我是 JIRA Agile（以前称为 Greenhopper）的新手，并且正在摸索它如何确定 sprint 容量以进行计划和燃尽估算。据我所知，假设 sprint 容量（以小时为单位）等于您添加到 sprint 中的问题的总需求 - 即，如果您将 40 小时的问题添加到 sprint 中，那么一旦 sprint 开始， sprint 的容量为 40 小时。
对我来说，这混淆了容量和需求这两个术语，如果它是这样运作的话。此外，这意味着我必须先使用外部工具或流程来进行容量规划，然后确保在开始之前正确设置 sprint。
我想知道其他人如何使用 JIRA 解决容量规划问题，以及是否有办法为发布规划目的指定每个 sprint 的 N 小时或故事点。
在 sprint 中解决容量规划时，任务/时间或故事/点几乎是无关紧要的。
使用故事点的好处纯粹是让您的开发团队更容易估计故事。当给定一些东西进行比较时，人们非常擅长估计相对大小。不太擅长根据过去的经验提供估计。在构建软件时，第二次以完全相同的方式做某事是很少见的。即使您确实看到涉及重复性任务，经验丰富的开发团队也会将其视为重构和概括可以快速轻松地重用的解决方案的机会，从而编写与第一次不同的解决方案。
第一步是确定用户故事包中最简单的任务之一，并将其称为 1 点故事。从那里你只需要回答这个问题，与你的“1”相比，做这个故事有多难。一旦您为几个故事完成了此操作，您将有一个更大的组进行比较，并且估计变得更容易。如果您遇到的故事与您可以比较的任何故事相差超过 2 个级别（例如，您估计的最大故事是 3 级，而您的开发团队说这是 13 级或更大），我建议您留下类似的故事这些直到你有更接近的比较。或者，您可以尝试将较大的故事分解为较小的故事，以便更容易估算。
作为项目经理，您需要做的就是利用这些故事点并计划下一个 sprint。“但我不知道冲刺多少分！” 你说……如果这是一个新项目或一个新的开发团队正在评估这些故事，请选择一些不超过 2 或 3 个的小故事，将它们分出子任务并让团队估计每个子任务。将总小时数相加并除以总点数，即可得出“空气中的湿手指”估计您的团队每个故事点需要多少小时。在每个 sprint 之后做同样的计算来得到你的平均“速度”（每个故事点的平均小时数）。
我知道在纯敏捷方法中定义的这个术语是完全不同的（每个 sprint 的故事点），我使用术语速度。我理解外部客户总是问“这需要多少小时？”，或者“这要花多少钱？”。在 PM 级别将故事点转换为小时数只会让报告和与客户交谈变得更容易，而无需对他们进行敏捷方法教育。
几十年来，我一直在与敏捷软件开发团队合作（无论是作为开发人员还是作为 PM），这就是我设法使这一切正常工作的方式。
希望这对游戏新手有所帮助。
@Shane，Sprint 容量由 Story points 决定而不是 hours 。通常，故事点不会转换为小时。这个想法是故事点更好地反映了团队的集体平均估计。
如果是第一个 sprint，那么每个 sprint 的故事点总是一个猜测。根据烧毁的故事点，您决定是否要增加/减少下一个冲刺的故事点
在敏捷（Greenhopper）中，您添加到 Sprint 的故事点因此是 Sprint 的容量。故事点字段不同于“估计”字段