BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Savita Pahuja 关注 3 他的粉丝 ,译者 李清玉 关注 0 他的粉丝 发布于 2015年8月18日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

待办产品目录修整就(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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT