我是JIRA Agile（以前的Greenhopper）的新手，并且正在考虑如何确定规划和烧毁估算的冲刺能力。从我收集的内容来看，假设sprint容量（以小时为单位）等于你添加到sprint中的问题的总需求 - 即如果你向sprint添加40小时的问题，那么一旦sprint启动，冲刺的能力是40小时。
对我而言，如果这是它的工作方式，这就是容量和需求方面的混乱。此外，它意味着我必须首先使用外部工具或流程进行容量规划，然后确保在启动之前准确设置sprint。
我想知道其他人如何使用JIRA解决容量规划问题，以及是否是一种为每个sprint指定N小时或故事点的方法，用于发布规划。< / em>的
答案 0 :(得分：1)
任务/小时或故事/积分在解决冲刺中的容量规划时几乎无关紧要。
使用故事点的好处纯粹是为了让您的开发团队更容易估计故事。当给出可比较的东西时，人们非常善于估计相对大小。仅根据过去的经验提供估算并不是那么好。在构建软件时，以第二次完全相同的方式执行某些操作是很少见的。即使您确实看到涉及重复性任务，经验丰富的开发团队也会认为这是一个重构和推广解决方案的机会，可以快速轻松地重复使用，从而编写不同于第一次的解决方案。
第一步是确定用户故事包中最简单的任务之一，并称之为1点故事。从那里你只需要回答一个问题，与你的“1”相比，这个故事要难得多少。一旦你为几个故事做了这个，你将有一个更大的组来比较，估计变得更容易。如果你遇到的故事距离你可以比较的任何故事都超过2级（例如你估计最大的故事是3，你的开发团队说这是13或更大）我会建议留下像直到你比较接近你的东西。或者，您可以尝试将较大的故事分解为较小的故事，以便更容易估计。
作为项目经理，您需要做的就是获取这些故事点并计划您的下一个冲刺。 “但我不知道有多少分适合冲刺！”你说...如果这是一个新项目或者正在估算这些故事的新开发团队，请采取一些不超过2或3的小故事，将它们分类并让团队估算每个子任务。将总小时数相加并除以总分数，为您提供“湿润的手指”，估计您的团队每个故事点需要多少小时。每次冲刺后，执行相同的计算以获得平均“速度”（每个故事点的平均小时数）。
我使用术语“速度”知道纯粹的敏捷方法中定义的这个术语是非常不同的（每个sprint的故事点）。我这样理解外部客户总是问“要花多少小时？”或“这要花多少钱？”。将故事点转换为PM级别的小时数，可以更轻松地报告并与客户交谈，而无需向他们介绍敏捷方法。
我几十年来一直在与敏捷软件开发团队合作（作为开发人员和PM），这就是我设法使其全部工作的方式。
希望这有助于游戏新手。
答案 1 :(得分：0)
如果是第一个冲刺，每个冲刺的故事点总是猜测。根据烧毁的故事点，您决定是否要增加/减少下一个冲刺的故事点
在敏捷（Greenhopper）中，你添加到Sprint的故事点就是Sprint的容量。故事Point字段与“Estimate”字段不同