


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. You can’t just take a chunk of one layer and call it a story. This is important to note when splitting epics into user stories. Each sprint is adding a small slice of each layer, like that vertical slice of cake. Instead, think of it like a slice of layer cake. That’s because these layers are not shippable features. This layered approach does not work for a Scrum development project, however. Sometimes these are built concurrently, and sometimes not. Many traditional projects build in layers – where different groups or resources build each layer (database, presentation, business, etc.). The Importance of Splitting Epics into Vertical Slices So stick with what you need right now and leave whatever’s left of your epic in epic form. As your product backlog priorities may change, it doesn’t make sense to invest all that time in planning every step out now.Ī sudden change in business direction, for example, could render all those efforts wasted. Only split off just enough to fill your next production sprint. But don’t waste time doing all that splitting work now. Splitting an epic can sometimes result in many user stories stretching over several sprints. And once the team gains momentum, we start tackling larger stories. At Ascendle, we split stories until they’re two or three story points each at the beginning of the project. As they get more comfortable with the process, velocity will pick up, allowing you to tackle larger stories more efficiently. Here you’ll want to either pick smaller stories for your sprints or split your larger stories into smaller pieces. So, if our average velocity is 15, then we really want our user stories to each rate five “story points” or less.Īt the beginning of a project, velocity will typically be much lower, especially if team members are new to agile development and Scrum. This tells us how much work we completed in that time. What we do at Ascendle is look at our average velocity over the last three sprints. 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. Some people might think a user story should match the length of the production 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. We don’t have shippable features to add to our product, either.Įssentially, 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. 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. 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. 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? 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. Why You Can’t Just Divide an Epic into Smaller Pieces

So how do we go about splitting epics? First, let’s talk about how not to do it. 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. That’s why you need a solution for dealing with epics. They want to be completing user stories and delivering shippable features on schedule. So your development team shouldn’t be taking them on – at least, not in that format. We call these stories epics, to give them that “larger than life” sort of feeling.Īn epic simply doesn’t fit into a production sprint. It’s certainly not a sprint.īut you’re going to be faced with large user stories like that from time to time. That might seem like nothing in traditional project management terms… but it’s forever in agile development terms. The engineers estimate it will take four months to develop. What happens when your user story is too big to fit into a production sprint?įor example, let’s say you have a piece of functionality in your product backlog.
