不要给予部分信任

对于那些在sprint结束前还没有结束的故事，你该怎么办?我们能得到部分信用吗?

我经常被问到这个问题。每个人都想知道是否要拆分故事，以及如何处理这些要点。不要对未完成的故事给予部分信任，或者进行不可测试的分裂。

不要将未完成的，不可测试的故事拆分

将未完成、未测试的故事转移到下一个sprint中，不要分割。拆分有什么好处?

有时人们告诉我，将来他们需要知道在这个sprint中完成了什么工作，这就是为什么他们要分故事。我从来没觉得有必要这么做。如果出现这个问题，您的敏捷工具的历史将显示您需要知道什么。

要劈叉太容易了。每个用户故事必须是适当的用户故事。不要草率。将故事分割成未完成和不可测试的部分是草率的。这是一个坏习惯，会在你的产品待办事项列表中以糟糕的故事形式出现。你必须学会自律。

不要给予部分信任

其他人告诉我，他们希望这个sprint的速度是正确的，以考虑到他们在未完成的故事上所做的工作。他们想要部分信贷。坏主意。

一旦你开始开发，一旦你做了一些设计并深入挖掘了细节，你就很难正确地估算出一个故事片段与其他你还没有开始开发的故事之间的关系。有关这方面的更详细解释，请参阅这篇文章不要在冲刺计划中进行估算。很难正确估计与产品积压中的其他故事相比，那些尚未开始工作的工作。如果你试图估计一个未完成的故事，那就特别努力，这是一个不满足你的部分“完成”的定义。千万别这么做。把整个故事转移到下一个sprint。

然而，我建议调低对故事的估计(永远不会了)，如果剩余工作的估算小于原始估算。我非常关心可预测性，保守的计划，以及不要夸大我的速度。在下一个冲刺中给出所有分数的问题(n + 1)是它使得最近的平均速度(通常超过3个sprint)在一个半月后，当这个sprint (n)的成绩不及格。一个半月后，没有人会记得我们将某个故事的所有要点带到下一个sprint中。没有人会意识到他们用来评估发布计划的速度异常之高。

事实上，一点都不要称赞

另一些人告诉我，他们想要得到报道工作的功劳。

我反对“部分学分”的概念。我反对一般的学分观念。没有信用。这不是为了获得荣誉。这是对速度的错误理解。甚至危险。

开发速度是帮助我们制定发布计划的工具。如果团队觉得他们需要得到表扬，组织中就会出现功能失调的行为。也许团队正在面临提高他们的速度的挑战，或者在他们的速度下降时受到斥责，或者正在与另一个团队的速度进行比较。如果团队觉得他们需要获得荣誉，他们就会在数字和速度上玩游戏是没有用的为了它的预定目的。

速度就是速度。这与信用无关。

更好的计划:干净利落地完成冲刺

在训练中，我非常重视未完成故事的问题。无论你做什么，无论你如何处理它们，未完成的故事都很难处理，它们会影响你的开发速度。除了干净利落地完成冲刺之外，没有什么好的解决方案。

比起知道如何处理未完成的故事，最好不要拥有未完成的故事。不要开始你无法在冲刺中完成的工作。在开始任何故事之前，首先看看团队是否同意它和其他已经开始的事情可以干净地完成。

停止启动并开始整理

这是由大卫·安德森,对吧?它的意思是在开始新的工作之前专注于完成已经开始的工作。Scrum团队可以从David身上学到很多东西。研究他的书关于敏捷管理和看板。

每天，在开始另一个用户场景的工作之前，团队应该考虑是否可以完成所有其他正在进行的工作和这是sprint结束前的额外故事。

在冲刺的后半段，团队应该开始询问是否有什么需要移除的内容，以便他们能够快速完成其他内容。如果多个故事似乎无法实现目标，那么就牺牲1到2个故事，现在就停止开发它们，适当地拆分它们(见下文)，或者将它们从sprint中剔除，这样你就可以干净利落地完成所有其他故事。

分裂Splitable故事

有这样一种情况，我将把一个无法完成的故事分成两部分，但你应该在冲刺的最后一天之前这样做，两部分必须满足投资标准，完成的一半必须完全符合完成的定义。

有时候，当团队有一个故事能够正常运行时，就会出现这种情况和测试但是遇到了一些特殊的错误场景或一些高级的可用性问题。我将把它分为基本故事和高级故事，或者愉快路径和错误处理故事。但是我总是将这样的故事分开，使两者都符合INVEST标准。它们必须都是真实的用户故事。完成的部分必须符合“完成”的定义并被产品负责人接受。

在这种情况下，如果团队可以决定如何分配分数，我可能会平分分数。(但不能说总数大于原数。)

结论

好了。无论出于什么原因，当你拆分一个故事时，请确保每一半都是一个合适的用户故事，符合INVEST标准。不会引起通货膨胀的速度通过增加被低估的故事的总点数来进行有风险的发布计划。完成sprint干净。忘掉试图为未完成的工作“获得荣誉”的想法。