Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Impact of Splitting User Stories on the Original Estimates

Impact of Splitting User Stories on the Original Estimates

This item in japanese


Product backlog refinement is a practice in which product backlog items are split and often re- estimated. Mike Cohn, one of the founders of the Scrum Alliance and owner of Mountain Goat Software recently wrote a blog on user story splitting and re-estimations.

Mike says that one of the reasons for splitting the stories is to understand them better. That improved knowledge should be reflected in any estimates they provide. If those estimates don’t sum to the same value as the original story, so be it.

Sometimes large user stories are broken down into smaller stories that are tackled by multiple teams. Jeremy Jarrell, Product Owner at Truefit, wrote a blog about splitting user stories across teams.

Even if a larger story that will ultimately be split across several teams we tend to keep it as a single story during the Product Backlog phase.  This helps to prevent us from getting mired in the weeds of each story too early and makes the story easier to move up and down the backlog as new priorities emerge.

Jeremy says that breaking the user story and re-estimating individual parts might impact the original estimates and won’t be accurate. He mentions that estimates are less reliable during this stage and only use them for getting an idea of the complexity of a story relative to other stories in the backlog.

However, during sprint planning the top stories in the product backlog are moved into a separate sprint backlog for each team. At this point those same large stories are broken down and split into separate stories for each team, which then take this opportunity to estimate their individual portions. The sum of those estimates may add back up to match the original estimate of the large story, but don’t be surprised if they don’t.  Breaking larger stories down into smaller stories often tends to expose gaps that we didn’t originally consider when the story was in its larger form, so new stories may emerge as a result.

Mike suggests using Planning Poker as buckets of water to protect you against a story becoming larger when split and its parts are re-estimated.

I’ve always written and trained that the numbers in Planning Poker are best thought of as buckets of water You have, for example an 8 and a 13 but not a 10 card. If you have a story that you think is a 10, you need to estimate it as a 13. This slight rounding up (which only occurs in medium to large numbers) will mitigate the effect of stories becoming larger when split.

Jeremy explains that a story point for one team may be wildly different than a story point for another team so the Velocity of two different teams may vary wildly even if each team is completing roughly the same amount of work. For this he proposes to map a separate velocity to each team, which better represents the amount of work they’re completing during a sprint rather than trying to roll all velocities into a single number.

Rate this Article