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.
- 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.