Story Splitting – Part 4

Story Splitting – Part 1

Story Splitting – Part 2

Story Splitting – Part 3

In previous post, we explored how a story can be split into multiple stories using Technology approach. In this concluding blog post, we will be exploring some miscellaneous approaches and thumb rules.

Path 1 (Acceptance criteria): A story might have a quite long list of acceptance criteria. To split a story you may relax acceptance criteria a little and later on expand the list.

Path 2 (Time line analysis): A story might be a series of steps which are time dependent in software execution. To split such a story you may consider some events initially and the add them using another story.

Path 3 (Dependencies): Especially in case of multiple teams, stories may have dependencies across teams. Even in case of a single team, stories might have dependencies. You may split such a story to reduce the dependency.

As a user,

I want to update price information of items on sale,

so I can items reflect correct prices at  website.

Note: In this story data feed needed to update the prices is coming from suppliers

As a user,

I want to update price information of items on sale,

so I can items reflect correct prices at  website.

Note: Ignore the price related data feed from supplier

As a user,

I want to update price information of items on sale (use price data feed from suppliers),

so I can items reflect correct prices at  website.

 While splitting a story, you may follow some thumb rules:

1.       To split a story choose grammar approach first and then business.

2.       Story splitting is a group exercise.

3.       Motives of story split are INVEST model, 3Cs and ensuring optimal size (1/6^th to 1/10^th of average velocity of team) of story.

4.       A story should be reach to DONE state in couple of days by couple of devTeam members.