Why Splitting Stories Is Helpful for Scrum Teams

6 January 2014

Khurram Mahmood
Citigroup


When we started our project a few years ago, there were cases where we were accepting large stories, and we would miss out on finishing one or two of them. The team's velocity was around 40 points per two-week sprint, and we were accepting 20- and 40-point stories in a sprint. We learned a lesson: Always split larger stories into smaller stories where possible and practical. There are quite a few reasons, including these:

Finishing stories within the sprint

If you are working on single large story in a sprint and are not able to finish it, despite working hard the whole sprint, you did not reduce the sprint backlog. The product backlog stays the same, which is a shame. Smaller stories, on the other hand, are easy to estimate correctly. This in turn means that even if you did not finish all the stories, there is good chance that you will finish most of them.

Better estimates

As most of us are aware, the larger the story, the more vague the estimate of its size. There are more chances that we will not finish the story on time. So with one large story there is a chance of not delivering anything; however, if it is broken down into three smaller stories, estimates will be more accurate and chances are the team can commit with confidence to two if not all three of the stories.

Small stories are easily described and tested

Large stories require more detail. Chances are strong that the development team will spend more time trying to understand them and may feel lost at times. Smaller stories, in contrast, are easily described and are more focused on a certain feature or part of a feature. Hence it is easy to have a crisp, clear understanding of the story -- which means that smaller stories are easier to implement and test.

Frequent feedback

Since you can finish smaller stories more quickly, you have more chances of receiving feedback. This means smaller stories are more Agile by nature.

Confidence level

Since with smaller stories the team is clearer on what is needed and there is less that can go wrong, estimates are more accurate. So with smaller stories, the team's confidence level grows in terms of estimating and implementing stories.

Article Rating

Current rating: 5 (1 ratings)

Comments

Paulo Dias, CSM, 1/6/2014 7:24:53 AM
Good points Khurram.

An estimate will always be an estimate. We can only aim to estimate as best as we can with the information we know at the time. The larger the story is the more difficult is to estimate because there are more chances to hit the unknown. So, if we keep our stories small, the estimates have better chances to be closer to actuals. That is why we use the Fibonacci scale for story points - to discourage people from planning large stories which will consume too many points.

Regards
Paulo Dias.
Khurram Mahmood, CSP,CSM, 2/10/2014 4:04:36 PM
Yes Paulo,
Fibonacci points assignments can be used as a great tool for ensuring:
A) Larger stories take into account vagueness in estimates of size.
B) Stops POs from pushing over specified and under specified stories towards development team.

You must Login or Signup to comment.