如何处理未完成的故事？

Scrum 团队常常发现：到了 sprint 结束时，还有一直在开发的故事没有完成。也许这个故事已经完成了 80%。是什么造成这样的状况出现？又该用什么样的流程来跟踪这些故事？每个敏捷团队都会面临这样的问题。 David Starr 在最近的一篇博客文章 中分享了他的处理方法。

跟踪的方法之一，是认为团队在当前sprint 之内完成了该故事80% 的点数。初看上去，这样做似乎准确反应了现状，而且会有利于跟踪团队的速度，不至于在各个sprint 之间表现得忽高忽低。团队也会因此而“感觉良好”。然而，这种方式有很大的风险。故事其实并没有完成，而真正要完成需要付出的时间和精力仍然是未知数。

第二个方法，是将故事分成更小的几个故事，并找出可以被认为已经完成的故事。相对上一个“部分得分”方式，这个方法中更小的故事确实“完成”了。这也使得产品负责人可以对于剩下故事的相对重要性做出判断。

David 发现所有“部分完成”的方式都不能令人满意，并且建议：除非故事完全完成，先不要将功劳算在团队身上。他还建议，重新估算故事，并放回到待办事项列表中。David 说：“这种方式让事情一目了然，而且团队也不能玩数字游戏了。”

你的团队如何处理部分完成的故事？请在评论中贴出你们认为哪些方式可行，哪些方式不好。

查看英文原文： How to Handle Unfinished Stories?

读者 Dave Rooney 认为，即使一个故事的大小可以放到 sprint 之中，也不能停止对该故事的切分。

这也与 Sprint 的长度有关。Sprint 越长，有些工作就越容易完不成。这看起来好像与我们的直觉不符。根据我的经验，人们很善于估算相对较少的工作，比如需要几天或者一周时间完成的工作。如果工作项越大，人们的估算准确性就越低。所以，除非再切分下去对与交付业务价值没有意义，就不能停止切分故事。 对于未完成的故事，这要视情况而定。我对团队反复强调，不要将未完成的工作算到上一个 sprint 的速度中，不过他们可以修正故事的估算，供下个 sprint 开发使用。