转载

切分用户故事对原有估算的影响

待办产品目录修整就(Product Backlog Refinement)是切分待办产品目录的条目并重新估算的一种实践。 Scrum Alliance 的创始人之一以及 Mountain Goat 软件 的所有人,Mike Cohn最近写了一篇关于用户故事切分及重新估算的 博客 。

Mike说切分用户故事其中的一个原因就是更好地理解他们。改进的知识应该反映在任何所提供的估算上面。如果那些估算的总和与原始估算不相等。那就随它去吧。

有时候,大的用户故事切分出来的小的故事会被多个团队处理。 Truefit 的产品负责人,Jeremy Jarrell写了一篇关于 跨团队切分用户故事 的博客。

就算一个大的用户故事最终会被多个团队切分,我们还倾向于在产品待办目录阶段作为单一的故事保留。这有助于防止我们过早地陷入细节之中,并且当新优先级的故事产生时,很容易在目录中上下挪动这个故事的优先级。

Jeremy说切分用户故事并重新估算各个部分也许会影响原始的估算,使其变得不准确。他提到估算在这个阶段并不可靠,只是用他们来得到一个想法,即这个故事相对于待办目录中其他相关故事的复杂性。

然而,在 Sprint规划 上,产品待办目录中高优先级的用户故事被挪到每个团队单独的 Sprint待办目录 中。这时,同样大的用户故事被细分,并被每个团队切分成独立的用户故事,然后借此机会估算他们自己的部分。那些添加部分估算的总和也许会与原有的大故事估算相匹配,但如果它们不一样也不要惊讶。把大的用户故事切分成小的故事更会暴露理解的差距,就是当以大的用户故事表现时最初没有考虑的内容,所以会产生新的用户故事。

Mike建议用 计划扑克( Planning Poker ,可以防止你的用户故事在切分和重新估算独立部分的时候变得更大。

在计划扑克中的数字最好是斐波纳契数列,我在书中一直这样写并在训练中也是如此,例如一张数字8和一张数字13的卡片,但没有数字为10的卡片。如果你认为一个用户故事是10,你需要把他估算为13。这种少数的舍入通常会在大的数字之间发生,这将减少把故事切成很大的影响。

Jeremy解释说团队的一个用户故事点,可能会比其他团队的一个用户故事点有很大差异。所以就算每个团队独立完成大致相同数量的工作,两个不同团队的速率也会大相径庭。就这一点,他建议每个团队有单独的速率,这样更好地展现一个迭代中完成的工作量,而不是试图把所有的速率滚成一个数字。

查看英文原文: Impact of Splitting User Stories on the Original Estimates

正文到此结束
Loading...