您将什么定义为障碍？我知道 Scrum 会这么说，而障碍会阻止团队发挥其所能做到的最好。所以基本上它可以是一切？但是它变成的神奇路线和内部改进在哪里呢？
例如。我们希望在我们的数据库中拥有更真实的测试数据，这是内部改进还是障碍？作为一个团队，我们可以尝试在 sprint 中直接与其他故事一起解决它，或者我们可以说这是一个内部改进，需要成为一个故事并进入产品 backlog。
在我看来，我们有三个选择： 1. 将所有内部改进作为待办事项中的故事处理，并让 PO 优先考虑它们。2. 在 sprint 中与他们一起完成常规故事。3. 大事以故事和小事的形式出现，我们可以直接在 sprint 中完成，而不会对速度产生太大影响。
你怎么处理这个？我们需要关于如何做到这一点的提示和想法:)
什么是障碍 障碍是阻碍团队前进的任何事物。这是一个非常开放的类别，可以包括以下内容：
我们经常关注显而易见的东西：工具和权威，但更多时候是阻碍团队前进的无形资产。比如团队凝聚力、知识和经验。
更真实的测试数据 不要将改进归类为内部与障碍。我们的目标是将改进嵌入到自然交付过程中。出于这个原因，我的第一个倾向是说所有的障碍和改进都应该在交付的背景下完成。您希望改进反映在交付能力上。我们希望我们的结果能够反映现实。有时，改进工作意味着我们以未来增长的名义暂时降低速度。有时我们甚至以质量的名义永久降低速度。
我建议你找到渐进的方法来达到你提出的最终状态，并在每次接触该区域、每次冲刺和/或每次准备另一次测试运行时实施一点点（假设它需要准备时间——如果没有的话- 极好的！）。
积压工作的改进 这是您的选择，您应该与您的 PO 讨论。请理解，虽然 PO 希望从 sprint 中获得高质量和改进的输出，但 backlog 的目的是从用户的角度代表有价值的功能/要求，而不是您的。出于这个原因，我会犹豫是否将改进项目放在待办事项上。您应该始终对每个积压项目进行改进。您的 PO 也可能不愿用他们认为应该作为正常交付的一部分完成的事情来填补积压工作。将其视为一个信号，即这些东西对用户没有直接价值，而是以可持续的速度提供高质量价值的成本。