Breaking Things Down. Splitting User Stories in Agile Development

Software projects can get out of hand quickly. Often, the problem lies in the requirements. Functions that were once thought simple and straightforward end up becoming a massive list of confusion, uncertainty, and frustration. These types of problems are easily avoided by striving towards good Agile principles. You accomplish this by building user stories that are Independent, Negotiable, Valuable, Estimable, Small, and Testable. Doing so often involves splitting large or complex them into separate stories. Below are a few suggestions on how to split user stories to ensure they meet these criteria.

One Step at a Time: If you find a story that has multiple steps to the workflow, it is best to separate each part of the step into its own user story. Start at the beginning of the workflow and build the user story for the first step. Then work your way through the workflow building and refining the middle use cases. Once the entire workflow is complete, you can go back and add the exception or alternate path user stories. In this manner, you'd simply keep building each step of the workflow from start to finish, until you have a working system.

And Then There Were Two: Often you find user stories that mask two or three stories as one. The first clue is if the user story contains words such as AND, OR, WHEN, and IF. For example:

• As an HR Specialist, I want to create employee records AND send them to the hiring manager so that I can get new employees registered into the system.

This story looks fine, however, the more appropriate approach is as follows:

• As an HR Specialist, I want to create employee records so that I can get new employees registered into the system
• As an HR Specialist, I want to send employee hiring records to the hiring manager so that I can get approval on the new employee.

In or Out: Another common approach is to split user stories based on direction of data flow through the system. In this approach, you would look to create stories that focus on data input and all possible variation of data input into the system. Then you'd do a separate set of user stories that address data flowing out of the system. Complex user stories are not necessarily a bad thing. They spark a discussion, collaboration, and creativity among the team which ultimately leads to a more engaged team, a better product, and ultimately a happy customer. We'd love to partner with your team to ensure the success of your Agile projects.