如果用户故事编写不正确，很有可能无法按时交付。这反过来又会影响其他人。所以要严格——我们也一直在收紧限制。现在，我们无法估计的用户故事根据定义会被推送到下一个 Sprint。那么：他们还不清楚吗？除掉它！
我们每周都会在周末之前做一些细化工作——这是 Sprint 的最后一周吗？然后我们称之为下一个 Sprint 的 Sprint Planning。我们在这方面领先于一般的节奏，以便我们可以在其他团队进行 Sprint 规划之前将我们的计划告知他们。那么他们也会及时知道哪些情况我们无法处理（因为我们已经满员或者因为规范不明确）。通常不会有任何意外，因为我会提前一周制定一个“影子蜘蛛计划”，并将其连同指示性计划和实例一起发送给 Scrum Master。
大多数集成需要两部分：数据建模和构建集成。一开始，这两个部分通常安排在两个连续的 Sprint 中，或者以六周的时间为前置时间。这有时会有点伤人......这就是为什么我们改为每周进行细粒度的规划。在 Sprint 规划期间，我们将所有用户故事放在 Sprint 的特定周内（这很简单，大多数用户故事需要 1-3 天的工作）。这意味着我们通常可以在一个 Sprint 内完成所有工作，有时甚至可 喀麦隆 数字数据 以让请求团队在第三周安排相关工作。团队对此非常热情，他们现在希望每天都进行规划。这是不可能的，因为兼职时间不同且有临时活动，但这是一个值得欢迎的回应！
结论
不要为了框架或方法而执着于框架或方法。当它开始成为一个问题时——不只是对您自己的团队，而且对其他团队也是如此——您必须找到另一种解决方案。到处挑选最好的选择，找到最好的工作方式。使用或创建您（需要）的灵活性，并且不要忘记“常识”框架。