关于快速修复的sprint中的其他故事

Question

我已经把斯普林特引入了我们的球队，在经历了一场艰难的开局之后，我们开始有节奏了。开发团队的一个观点是，他们仍然希望能够在“容易”的bug和增强请求上工作，因为这让我们的客户(我们的组织内部)很高兴。毕竟，这就是游戏的终点，对吧？

无论如何，我的立场是，只要它不影响所承诺的冲刺，就可以这样做。如果是这样的话，我们必须评估优先级，并将其添加到下一个sprint中。这已经取得了很好的效果，但我开始认为，从规划的角度来看，这不是最好的选择。

问题是，我要求他们将新作品的故事添加到sprint中，并对其进行调整，从而增加sprint中的点数。

我担心的是，我将在明年引入3个月计划，届时我们将使用最后5个sprint的速度来规划我们在未来10-12周内可以承诺的故事数量(即速度* 5-6周冲刺)。

我是否创造了一个错误的经济(速度)，允许开发人员为bug和“容易”的增强添加和大小故事冲刺？还是该走这条路？

Answer 1

你说你最关心的是这些小事对你评估能力的影响。然而，事情是这样的:错误修复和小功能“快速获胜”是有用的。它们计算出你的速度。你应该规范和估计它们(用故事点或你正在做的任何事情)，这样你就可以将它们纳入你的速度数据中。换句话说，他们不是分散工作的注意力，而是工作。

你还没有说你在Scrum团队中扮演了什么角色，但你听起来像个Scrum大师。我要问你的问题是:你的产品负责人对此有何看法？这是他们的决定。即使在sprint过程中，完全取决于您的PO是否会将这些事情的优先级提高到足以建议将它们插入sprint中，以及开发团队的责任来说明他们是否会将它们协商到sprint计划中。如果有人直接将这种事情带给开发人员，他们需要被重定向到产品负责人。

冲刺计划不是承诺，而是预测。没有什么是固定在石头(甚至“承诺-到”)的冲刺计划。sprint计划表示团队预测可以完成他们在计划期间制定的Sprint目标的工作。

你正在为每一次冲刺制定斯普林特目标，对吗？您可能会考虑添加"...while使客户对我们对他们的需求的响应满意“这样的东西，这样的话，这些事情就不会完全脱离目标。

Answer 2

你听起来像个船长，因为你的划手们花时间把水从你漏水的船里救出来，这让你很难过。保释不会给你带来你想去的地方。但忽视救助会让你陷入低谷。

简单的事实是，你的团队需要做一些救助。他们还需要午休。回家去见他们的家人。偶尔睡一觉。真正的问题是，在冲刺中跟踪这些东西有帮助吗？

冲刺计划并不一定是人们为自己的工作而获得的信贷的唯一仲裁者。如果不是这样的话，你可以通过把这项工作排除在计划之外，来减少每个人的噪音。修复琐碎的bug和添加一些琐碎的特性在sprint中可以被忽略，就像浴室休息一样。

你担心它会影响速度测量。如果这些琐碎的bug和特征突然干涸或者加倍的话，那就有可能了。但是要知道，只有一个团队和3个月的数据速度是非常模糊的。不管有多少琐碎的工作是最小化的，速度还不会做很多，除了让团队更加保守的预测，他们可以完成在一个给定的冲刺。这是最好的利用。

如果您希望跟踪这项工作，那么您绝对需要允许开发人员为“轻松”的bug和增强添加和调整故事。我不建议把这个从他们身上拿走。我会鼓励优先处理任务，先做更难的事情。