我所在的团队正在交付产品。我们正在为regression sprint 做准备，这将是下一个冲刺。在这个 sprint 中testers 将不得不测试整个应用程序以确保应用程序处于稳定状态。
问题出在开发团队中，实际上我们完成了当前版本所需的任务队列，我们有一个很大的任务队列，但在另一个版本中。
我可以想出两个办法来解决这个问题
提示：我们的测试资源有限，因此我们无法提供测试回归的团队
【问题讨论】：
没有“回归测试冲刺”之类的东西。这在术语上是矛盾的，因为冲刺包括交付潜在可交付软件增量所必需的一切。
在 Scrum 中，我们在我们称为冲刺的时间框内进行开发、测试（包括回归测试）。我们这样做是因为：
当您保存回归测试时，您会产生错误的进步印象。某些功能看起来可能已经完成，但实际上在经过回归测试之前，无法知道还剩下多少工作（例如，可能存在要修复的回归错误）。
有趣的是，您说您的测试资源有限。我怀疑你的意思是你有有限的人有“测试员”的标签。开发人员可以进行回归测试。他们甚至可以编写自动化回归测试，这是进行敏捷开发时特别强大的方法。
在您目前的情况下，我建议您有 sprint 致力于完成出色的工作。这意味着回归测试和错误修复。如果开发人员没有要修复的错误，他们应该帮助进行回归测试（手动或编写自动回归测试）。
对于未来，尽量不要让测试与开发不同步。力求在“完成”状态下完成每个故事的每个 sprint，包括回归测试和为产品发布做好准备所需的任何其他工作。
【讨论】：
您可能希望在未来重新审视您的开发流程
你逐渐开始避免像现在这样的情况。
假设：您没有维护一个庞大的遗留系统（cobol），其中强化 sprint 或更多可能有意义。
目前选项 2 看起来是最好的折衷方案，假设您的开发人员将帮助测试并且测试人员不会发现太多错误，以至于您需要新的 sprint 来修复新的回归等错误：)。
【讨论】：