The strategy of splitting stories is to split them as late as possible to fit in a sprint just before the sprint that will take them on. Think of it as playing the classic arcade game Asteroids: you only want to break up the large asteroids when they are an immediate threat to you or when you've cleared out the smaller, more dangerous rocks…break up too many of them too soon and the resulting cloud of small asteroids will kill you.
Similarly, if you break up a bunch of epics into a large number of sprint-sized stories, the resulting backlog bloat will cloud vision and diminish your response to change.
There are a lot of good tips on how to split stories, like this one. In this post, I'm going to suggest some of the more common splitting techniques used for video game development.
A couple goals exist for splitting stories:
- Each of the split stories should have some value to the user.
- The split stories should be able to be prioritized against one another.
Split along research/prototype dependencies:
Example: As a player, I want to react to impacts.
A suggested split:
⁃ As a designer, I want to know where an impact occurs.
⁃ As a player, I want to react based on the impact location.
Reasoning: The first story allows some research on collision physics and helps the team and designer experiment with different strategies. (e.g. would a simple strategy of having high, mid and low collision volumes be good enough, or do we need something more complex?)
Split along conjunctions:
Example: As a player I want to smash wooden crates and doors open.
A suggested split:
⁃ As a player, I want to smash wooden crates open.
⁃ As a player, I want to smash wooden doors open.
Reasoning: Do the simplest or most important first. Also note that the first of anything is usually more expensive, so this makes it easier to see costs by sizing these stories individually.
Split by progression:
Example: As a player, I want to be coached on the rules of poker and ways I can improve my home game.
A suggested split:
⁃ As a player, I want the game to have some first-time user experience (FTUE) tips for playing poker.
⁃ As a player, I want the game to give me tips for improving my home game.
⁃ As a player, I want the game to evaluate my hand strength and suggest the next move.
Other splitting strategies include:
⁃ Split by acceptance criteria. Acceptance criteria often make perfect stories themselves.
⁃ Split by discipline capacity. E.g. if you don't have enough animation support, then you might have to split off a "Add polished animations to..." story for the next sprint (after you've done everything else to avoid this).
There is one consistent splitting technique that teams new to agile have a hard time avoiding. This is splitting stories along component design or discipline effort. Teams new to agile are used to breaking up features into a plan to develop all the “parts”, which will become useful sometime in the future.
Example: As a player, I want a third person camera that can transition smoothly between a loose camera in open spaces and a tight camera in small spaces that avoids collision with the surrounding geometry.
A poor split would be:
⁃ As a programmer, I want to create a camera manager that will handle transitions between all future cameras.
⁃ As a programmer, I want to implement a camera collision system that will avoid camera collisions or occlusions from the surrounding geometry.
The reason these are poor splits reflects agile values and principles that building emergent, working software is better than following a never-perfect-yet-detailed plan which delays that emergence. A better approach to splitting might be:
⁃ As a player, I have a simple polar camera that follows me around.
⁃ As a player, I want the distance between me and the polar camera to be based on how close the surrounding geometry is.
⁃ As a player, I want the the camera to have a collusion box around it to avoid going into surrounding geometry.
⁃ As a player, I want the camera to linearly interpolate its position as a rotate.
There are several advantages to this:
- The rest of the team gets a camera sooner. This allows work and feedback to continue (rather than finding “something else” to work on in parallel).
- Unless you are in the position of being 100% certain of the requirements of the camera system (something I’ve rarely seen on a team), there’s less of a chance that the system developed will need major rework.
- Emergent development will often save a lot of time by identifying what we don't have to build. I relate a story of this in another article.
This is not to say there aren't features that can be fully planned and executed without iteration. The trick is to not fool ourselves into the belief that we can plan away uncertainty.