As product owners, scrum masters, and agile team members work together to build a backlog for their product, they will inevitably run across large user stories. When a user story is expected to take longer than about a quarter of a sprint, then it is a good ideal to break it down into smaller pieces of work. These smaller user stories can be children of the longer original story, now know as an epic.
There are several ways to break down an epic. Some possibilities include:
1. Break down the epic by user interface components, each workflow required by the user can be a separate user story.
2. Break down the epic into research, implementation, and test phases.
3. Break down the epic by phases – first do a simple implementation, then add functionality with each additional user story.
The agile team should discuss and decide together on a the right way to break down each epic. Typically this happens in a planning session right after the team sizes a story and decides it is large enough to be considered an epic.
Key questions to consider when breaking down the epic are:
1. Can each of my new user stories be demonstrated?
2. Can each new user story be sized easily?
3. Are any of the new user stories of epic size? If so, they should be broken down further.
4. Are each of the user stories a complete piece of work? Does the breakdown make sense?
It is very important to break down and write user stories at the right level of granularity. If a user story is too large, the team runs the risk of losing momentum when working on the story. If the user story is too small, the team could spend nearly as much or more time in overhead creating the story, sizing it, and marking it as complete than it takes to actually do the work. Writing properly-sized user stories gets easier as an agile team matures and becomes more experienced with sizing and story creation. See also: How to Write a User Story in 4 Easy Steps