What happens when your user story is too big to fit into a production sprint?
For example, let’s say you have a piece of functionality in your product backlog. The engineers estimate it will take four months to develop. That might seem like nothing in traditional project management terms… but it’s forever in agile development terms. It’s certainly not a sprint.
But you’re going to be faced with large user stories like that from time to time. We call these stories epics, to give them that “larger than life” sort of feeling.
An epic simply doesn’t fit into a production sprint. So your development team shouldn’t be taking them on – at least, not in that format. They want to be completing user stories and delivering shippable features on schedule.
That’s why you need a solution for dealing with epics. You need to make them smaller. You need a way to fit them into your production sprints without disappearing into the “black box” for four months – the black box with which most business leaders are well-acquainted and dread.
So how do we go about splitting epics? First, let’s talk about how not to do it.
Why You Can’t Just Divide an Epic into Smaller Pieces
One obvious way to split an epic into production sprints is to just divide it into sprint-sized pieces, without splitting it into separate user stories. For example, if the epic is estimated to take four months to complete, why not just divide it into four-month-long production sprints, or eight two-week sprints?
This, of course, would violate one of the fundamental rules of Scrum: one or more stories must be potentially shippable by the end of each sprint.
If all we do is break our epic into four equal pieces, we’re still delivering that feature at the end of the last sprint, which means we don’t have working demos to share with our business owners in sprints one through three. We don’t have shippable features to add to our product, either.
Essentially, all we’ve done is actually make that epic take longer because we’re tacking on additional project overhead at the bookends of each sprint. We’d be better off going into our black box for the duration and getting it done, since that’s all the business owners will see anyway.
How Big Should a User Story Be?
Some people might think a user story should match the length of the production sprint. But that’s not the case at all.
In each sprint we ideally want to complete three or four user stories from our product backlog, which means we need to pare down our larger stories and epics into much smaller sizes.
What we do at Ascendle is look at our average velocity over the last three sprints. This tells us how much work we completed in that time. So, if our average velocity is 15, then we really want our user stories to each rate five “story points” or less.
At the beginning of a project, velocity will typically be much lower, especially if team members are new to agile development and Scrum. Here you’ll want to either pick smaller stories for your sprints or split your larger stories into smaller pieces. As they get more comfortable with the process, velocity will pick up, allowing you to tackle larger stories more efficiently. At Ascendle, we split stories until they’re two or three story points each at the beginning of the project. And once the team gains momentum, we start tackling larger stories.
Only Split What You Need Now
Splitting an epic can sometimes result in many user stories stretching over several sprints. But don’t waste time doing all that splitting work now. Only split off just enough to fill your next production sprint. As your product backlog priorities may change, it doesn’t make sense to invest all that time in planning every step out now.
A sudden change in business direction, for example, could render all those efforts wasted. So stick with what you need right now and leave whatever’s left of your epic in epic form.
The Importance of Splitting Epics into Vertical Slices
Many traditional projects build in layers – where different groups or resources build each layer (database, presentation, business, etc.). Sometimes these are built concurrently, and sometimes not.
This layered approach does not work for a Scrum development project, however. That’s because these layers are not shippable features. Instead, think of it like a slice of layer cake. Each sprint is adding a small slice of each layer, like that vertical slice of cake.
This is important to note when splitting epics into user stories. You can’t just take a chunk of one layer and call it a story. The piece you split off must be a complete slice of cake in and of itself – with all the layers necessary to demo a shippable product.
The Art of Splitting Epics
There is no hard and fast rule for how you should split an epic into multiple user stories. It’s more of an art form, really – your team will begin seeing patterns and trends to make it easier as they gain more experience with it.
Here are some suggestions for ways to split epics into stories:
- Data Boundaries: Divide the epic into separate bits of functionality along data lines. One user story could enable a company data display, for example, while another would display that company’s contact info.
- Operational Boundaries: Reduce the epic to its minimum viable feature, then build it out with additional slices of functionality.
- CRUD: Break up your feature set by what users can do with it in terms of Create, Read, Update, and Delete. Each of these could be a separate user story if needed.
- Cross-cutting Concerns: Separate out certain properties that all features need to incorporate, which can then be addressed as separate user stories. These include items such as validation, security, and exceptions.
- Non-functional Requirements: Address overarching items like performance and capacity as separate user stories. For example, if an app needs to handle 500,000 users, that doesn’t need to be incorporated into the first user story of each feature. Get the feature working first, then address the capacity issue with a new
story.
