Splitting Stories

Mike Cohn provides guidelines on splitting stories in his books Agile Estimating and Planning as well as User Stories Applied. Stories need to be split as they rise to the top of the product backlog and near implementation. Some reasons for splitting a story are:

1. Size – Too big

• a. Cannot give an accurate estimate: A story needs to be more manageable and enable a more accurate estimate.
• b. Cannot fit into an iteration: If for example an iteration is 1 week long and the story in longer than a week then it needs to be split to fit into the iteration.
• c. Cannot fit into what’s remaining of an iteration: A team has already committed to 38 story points and there is still room for a 2 point story but the remaining stories are 3 story points or more.
• 2. Dependency: A story is dependent on another story. This makes it hard to give a correct estimate. The story needs to be split where one story handles the dependency and the others handle the specifics.
• 3. Risk: A story is complex and risky. The story needs to be split to create a spike story which is experimental in nature and its main goal is to gain technical knowledge.
• 4. Compound: A story contains multiple sub stories that are large enough to stand out on their own.

Some of the techniques for splitting stories include:

• 1. Along data boundaries: For example, separate local requirements from international requirement, or handling one type of credit card from another.
• 2. Operational boundaries: This typically is done along CRUD boundaries where for example a story is split into 3; one to create an entity, one to retrieve and update an entity, and one to delete an entity. Another example might be separating a story into search which simply return search result count and then search display which displays the actual results of a search.
• 3. Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features. For example, a screen that will have different menu options or links based on the login user’s credentials. This security specific feature can be split from the main functionality of the screen.
• 4. Performance constraints: Functional requirement from non functional requirements can be split into separate stories. For example, a feature can be enabled without caching and then another story can handle caching specifics.
• 5. Priority: Within a story, there might be multiple priorities. For example, a login story might have different priorities for authentication than for handling error conditions like locking out a user after multiple logins.

It is important to not split stories into tasks like design, code front end, code middle tier, code back end. It is almost always better to deliver a cohesive subset of all layers of a feature than delivering all of one layer as a standalone. Having the entire backend ready without a corresponding GUI is not very useful, but having a feature that allows the user to add an entity through the GUI and have it persisted is functionality that can be useful and provides some value.

Finally, there might be cases where we might want to combine many small items onto one larger story. For example, bug reports can be combined into one Fix Bugs story.