来自wikipedia：
在每次“冲刺”期间，通常是两次 到四周时间（长度 由团队决定），团队 创造了潜在的可交付性 产品增量（例如， 工作和测试软件）。这套 进入冲刺的功能来了 从产品“backlog”，这是一个 优先级高级别 工作要求。哪一个 积压物品进入冲刺是 在冲刺计划期间确定 会议。在这次会议期间， 产品负责人通知团队 他产品积压中的物品 或者她想要完成。 团队然后 确定他们能做多少 承诺在下一个完成 冲刺。在冲刺期间，没有人 允许更改sprint积压， 这意味着的要求是 为那个冲刺而冻结。冲刺后 团队演示完成了 使用该软件。
我正在读这篇文章并立即突然出现两个问题：
1）如果冲刺只有几周时间，在一次会议中决定，你如何准确地计划可以实现的目标？根据我的经验，无法准确估计高级任务，并且可以轻松地将看似合理的任务加倍。作为一名开发人员，我讨厌根据一系列客户要求，在下个月推出我能提供的服务。这违背了我所知道的关于生成可靠估计的所有内容，而不是粗略估计然后加倍！
2）由于要求被锁定并且最终可以获得可交付产品，当某些事情需要两倍的时间时会发生什么？如果此功能在冲刺结束时只完成了1/2，该怎么办？
维基文章继续讨论Sprint计划，其中将事情分解为更小的任务进行估算（<1天），但这是在Sprint功能已经计划并且发布达成一致之后，不是吗？有点像推销员在没有咨询开发人员的情况下做出承诺。
顺便说一句：
虽然这个词不是首字母缩略词， 一些公司实施 已知过程拼写它 大写字母为SCRUM。这个 可能是肯施瓦贝尔之一 早期论文，将SCRUM资本化 在标题中。
答案 0 :(得分：4)
您应该使用velocity来计划下一个sprint。速度巧妙地处理了您的估计 错误的事实，但它们始终是错误的。还要注意故事应该很短，我说最多2-3天。比这更大的故事应该分解成更小的故事。
如果一个故事没有按计划完成，那么你的速度会下降，你将无法在下一次迭代中完成更多的工作。
答案 1 :(得分：3)
维基文章继续讨论Sprint计划，其中将事情分解为更小的任务进行估算（<1天），但这是在Sprint功能已经计划并且发布达成一致之后，不是吗？
错了，他们是在同一次会议上完成的。在每个人都离开冲刺计划会议之前，冲刺的故事都没有达成一致。无论您需要什么样的问题，PO都可以让您对故事做出承诺;你在SP会议之前或之中做过
由于要求被锁定并且最终可以提供可交付产品，当某些事情需要两倍的时间时会发生什么？如果此功能仅在sprint结束时完成1/2，该怎么办
故事的功能目标是锁定的，而不是实现细节。冲刺期间的细节会出现细节。任何被认为包含在当前sprint范围中的详细信息都会被放回Backlog中，以便以后确定优先级。请记住，您在此处构建增量产品。就像剥洋葱一样。必须满足这个故事，并且代码必须在sprint结束时工作。这并不意味着整个功能完全完整且可以发布给用户。
如果冲刺只有几个星期，在一次会议中决定，你如何准确地规划可以实现的目标？根据我的经验，无法准确估计高级任务，并且可以轻松地将看似合理的任务加倍。作为一名开发人员，我讨厌在下个月根据一系列客户要求推出我能提供的服务，这与我所知道的关于生成可靠估算的所有内容相比，而不是粗略估计然后加倍！
你在这里是对的，你无法准确估计。 Scrum拥抱这一事实，并使用速度，趋势，平均和肠道感觉来接近。如果你没有忘记准确的小时增量测量，你就不会对scrum感到满意。
答案 2 :(得分：1)
当我们在早期项目中进行SCRUM时，我们首先就粗略冲刺计划达成一致，包括高级功能（故事），然后通过将每个计划分解为最佳长度为1天的具体任务组来完善计划。 ，估计每项任务。在此之后，我们经常发现原始计划在某种程度上过度使用（通常是因为我们没有考虑到开发故事包括单元测试，代码审查和文档），所以我们相应地进行了调整。顺便说一下，我们使用“估算扑克”：每个成员选择一张带有数字的卡片（工作时间/天），每个人都显示他的卡片数为3.如果数字差异很大，我们会简要讨论为什么，然后有新一轮直到我们达成共识。
另请注意，估算非常依赖于域和技术。在那个项目中，我们都很了解，我们从头开始构建一个新的应用程序，因此我们的估计相当准确。在我目前的项目中，我们正在使用遗留代码，在我们还不太了解的域中，因此我们的估算通常超出范围。
随着项目的推进，估计会逐渐变得更好（与越来越多的风险和棘手问题得到解决以及团队的专业知识增长这一事实有关），因此团队的速度实际上会随着时间的推移而增长
答案 3 :(得分：1)
在回答＃2时，如果在sprint结束时没有完成某个功能，则不会发送它。您可能能够提供部分内容，如果您能以有用的方式完成，请执行此操作。但是如果你不能提供这个sprint，请将其删除，然后在下一个sprint中提供它。
在回答＃1时，有很多方法可以尝试提高估算的准确性。您可以使用功能点分析或仅仅是一个简单的练习，其中整个项目团队分别获取任务列表并为每个任务提出自己的估计，然后检查每个任务并分享他们的估计，并讨论原因（对于例子）Bob对此任务的估计是8h，Tina是16h。团队确定谁是正确的（希望）或达成共识，并将其用作估计。
随着时间的推移，你会发现你的哪些估计过于乐观，哪些过于悲观，从而提高你估算自己任务的能力。
刻录图表可以真正帮助您。它是整个项目团队的预警系统，让大家知道一个或多个人落后的时候。然后，团队可以重新组织以帮助在必要时做出冲刺承诺，或者由于不可预见的情况取消冲刺，并通过他们对问题空间的更好理解开始新的冲刺。
最后，您可能会认为统计数据就在您身边。如果你高估了10％的任务，并且低估了10％的任务，你可能会没事。
答案 4 :(得分：1)
在回答＃1时，我不确定我是否同意问题中的一些内置假设。根据我的经验，敏捷（包括Scrum）不是关于时间估计。整个想法是远离它，而是转移到一个系统，在这个系统中你有一个已知的速度和特定的冲刺时间。例如，您使用一些新代码每2周发布一次（良好的冲刺时间）。你可以看到你通过冲刺完成了多少故事点（不是时间单位，但是故事点），然后是另一个故事点，在你完成一些冲刺之后你会知道你的粗糙速度（即你可以做多少故事点）平均每个冲刺）。
这个想法是，当每个sprint完成并且可以看到持续的进展时，客户可以获得对应用程序的持续更新。他们知道哪些项目计划在未来的短跑中出现，但是他们知道如果事情滑倒（因为不正确的难度等级，即故事点估计，或者是外部问题），它将反过来进入下一个冲刺和其他一切将被移出一点。
所以它不是基于一些看似随意的估计来开发软件。相反，它关于规划您想要的功能或功能，并为这些功能（相对于其他功能）分配难度（故事点），并通过它们来确定速度。只有这样才能获得粗略的估计。一旦知道平均速度，我们就可以对时间框架做一些粗略的猜测。然而，即使这些也应该被认为是粗略的近似，因为它不是时间，而是关于不断发布的特征。显然，这种心态必须与团队中的每个人共存，而不仅仅是工程师。
这里有a link (wikipedia)更多内容。
无论如何，我希望这对你有所帮助，祝你好运！
答案 5 :(得分：-1)
实际上非常简单： 您优先处理任务，如果您发现没有足够的时间，那么低优先级的任务就会被删除或移动到下一个sprint中。
项目所有者决定他想要什么并设置优先级，然后按照该顺序开发。您应该在sprint结束时使用可用产品，而不是功能齐全的产品。