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