如何处理未完成的故事?

阅读数:138 2008 年 9 月 22 日

话题:敏捷文化 & 方法

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

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

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

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

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

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


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

这也与 Sprint 的长度有关。Sprint 越长,有些工作就越容易完不成。这看起来好像与我们的直觉不符。根据我的经验,人们很善于估算相对较少的工作,比如需要几天或者一周时间完成的工作。如果工作项越大,人们的估算准确性就越低。所以,除非再切分下去对与交付业务价值没有意义,就不能停止切分故事。

对于未完成的故事,这要视情况而定。我对团队反复强调,不要将未完成的工作算到上一个 sprint 的速度中,不过他们可以修正故事的估算,供下个 sprint 开发使用。