我所在的团队目前正在交付产品。我们正在为regression sprint做准备，这将是下一次冲刺。在这个sprint中，testers必须测试整个应用程序，以确保应用程序处于稳定状态。
问题是在开发团队中，实际上我们完成了当前版本所需的任务队列，而在另一个版本中，我们有一个很大的任务队列。
我可以想出两个方案来解决这个问题
- 与一些测试团队进行回归，并让另一个测试团队加入开发团队，在下一个版本中工作
- 致力于回归的冲刺&错误修复
提示：我们在测试方面的资源有限，因此我们无法提供测试回归的团队
没有所谓的"回归测试冲刺"。这在术语上是矛盾的，因为sprint包含了交付潜在的可交付增量软件所需的一切。
在Scrum中，我们在我们称之为sprint的时间框内进行开发、测试（包括回归测试）。我们这样做是因为：
- 我们希望在每一次冲刺中都提供可工作的软件
- 我们想真实地反映进展
当你保存回归测试时，你会给人一种进步的错误印象。看起来某些功能已经完成，但实际上，在进行回归测试之前，无法知道还有多少工作要做（例如，可能有回归错误需要修复）。
有趣的是，你说你的测试资源有限。我怀疑你的意思是，你有有限的人有"测试者"的标签。开发人员可以进行回归测试。他们甚至可以编写自动化回归测试，这是进行敏捷开发时一种特别强大的方法。
在你目前的情况下，我建议你让sprint致力于完成出色的工作。这意味着回归测试和错误修复。如果开发人员没有bug需要修复，他们应该帮助进行回归测试（手动或编写自动回归测试）。
对于未来，尽量不要让测试与开发不同步。目标是在"完成"状态下完成每一个冲刺，每个故事都包括回归测试和为生产发布做好准备所需的任何其他工作。
您可能希望重新访问您的开发过程，以便在未来
- 通过各种测试的自动化（由开发人员完成）
- 和/或通过在sprint x+1中添加一些时间来修复在sprint x中发现的错误
- 和/或通过制作可以在单个sprint中实现和验证的较小故事（请参阅sprint的大小）
- 和/或文化的转变，如果dev和qa被视为不同的团队
你逐渐避免了像现在这样的情况
假设：您没有维护一个巨大的遗留系统（cobol），在这个系统中，强化sprint或更多可能是有意义的。
目前，选项2看起来是最好的折衷方案，假设您的开发人员将帮助测试，并且测试人员不会发现太多错误，因此您需要一个新的sprint来修复错误、修复新的回归等：）。