BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

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

Bookmarks

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

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What if you think that the story is worth 13?

    by Richard Richter,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm not quite sure here, not an experienced agile practitioner, but arguing that card with 13 is good when you think it may be just 10 sounds fishy to me. Should you automatically pull out the next card after 13 when you think it is 13? Or 12... 11? The rest of the resoning sounds all like part of the story of solving this problem, but this particular argument sounded like "let's just double the estimate" (which, paradoxically, usually works great even if the developer did it internally by themselves).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT