One of the dangers of writing user stories is that they can get pretty big if there’s no one on the team to point it out. The scope of a user story becomes broader than it should be. In the following article, I’m going to walk you through the reasons why you should aim for small stories, the signs indicating that the story should be split, and some examples on how you can do the story splitting.
Do take into consideration that whenever I mention “story splitting” or “story slicing”, I mean vertical slices (top to down, from the user interface to the database), not horizontal ones (one slice per application layer). The reason for preferring vertical to horizontal slicing is simple: until you integrate all the layers together, the feature is not usable. Therefore, the user story is not done.
Splitting user stories – Why, When, How
Even though the INVEST model is actually a guideline to create good user stories, we can use it as a prism through which we can find the “why”, the “when” and the “how” of splitting user stories.
The S in INVEST stands for small. Why should the user story be small? The answer to that question can be found in the E of INVEST: easier estimation. One of the conundrums of our industry is estimating the delivery date of software. The practice of story slicing, to the point where one story is ready to use after a trivial amount of time, leads to the ability to correctly estimate. Ideally, a story should be finished in 2 or 3 days. If you’re not able to confidently say it can be done in that time slot, then you need to split it.
On that same note, the story is not small enough if it cannot be tested easily (the T of INVEST). A long list of bootstrapping steps in order to properly test is a sign that you need to split the story. A single “given / when / then” block should be the test description to be striving for.
Another sign is the I which stands for independent. It would be a lie to state that all user stories should be independent of each other. It is, in fact, impossible to remove some dependencies between certain user stories. Taking eventrix.co as an example, the speaker cannot submit a talk if the event organizer has no way of publishing the call for speakers.
So the idea of independent stories must be taken into the context of a development iteration: one story should not depend on another that is being developed in the same iteration. If that is the case, they should be split so that the dependency is removed. If that cannot be done, then the story depending on the other should be postponed to the next development iteration.
You can fall into the trap of splitting a story too much. Luckily, there is an easy way of figuring out if your story is too thin: the V in INVEST. A user story should bring value to the end user. If you user story cannot be demo-ed to the client or to your users, if it consists only of work that has nothing to show for it, then you know you split the user story too much. Or you cannot call that a “user story” anymore. It is something else: a maintenance task, a server configuration, a code cleanup, etc.
Finally, the N stands for negotiation. Use the big story as a starting point and negotiate its scope with the team. Anything that can be left out or delayed, should be. This way, you’re effectively splitting the story into something much smaller and more reasonable.
A simple rule to follow
Almost every session of user story splitting comes down to this rule: go from simple to complex. Break down your big chunk of work into the tiniest bits, manageable on their own. Is it a complex web form that you’re trying to build, one with all the bells and whistles, animations and what not?
Don’t do that upfront. Start with building a plain HTML form, first. Once you get that up and running, you can move on to the next simple thing on the list. For example, replace the dull file input field with that fancy web component. The next simplest thing you could do is to add one animation. And so on.
Make it work, Make it right, Make it fast
A common idiom in software development is “Make it work, make it right, make it fast”, meaning that developers should not be focusing on everything at once when developing a feature. This idiom can be used for slicing user stories by splitting the work according to those three characteristics.
First, let’s tackle the “make it work” part. More often than not, development time is wasted on attempting to make a feature blazing fast performance wise. But you should be asking yourself: is it worth it? There is value into a working feature, even if it is suboptimal. The first slice of your big story is to make the “happy path” work, even if the implementation is taking a naive approach.
The next slice should be related to the “make it right” part of the idiom. Some could argue that it means that you should then focus on refactoring the code, making it clearer. While this is true, a noble and mandatory goal, we all know you shouldn’t define a user story focused only on refactoring. It’s not right, it defeats the purpose of a user story. What you could do instead is focus on the other meanings of being “right”, taking care of validation and edge cases. Make a slice out of each special case and validation required.
Then and only then you can deal with performance optimizations, the “make it fast” part. You can even delay taking care of performance until you hear users complaining. And then, you should settle for reasonable thresholds when defining what “fast” means. For example, an acceptable time to wait for a web page to load can be set at 1-2 seconds, such that the users feels no interruption to their workflow.
Split by variations
Sometimes the user story gets so big because of all the variations being crammed into it. Let’s see a few examples and how to deal with each case.
Consider an e-commerce web page displaying a list of products. This page needs to show different things depending on who is looking at it. For a casual visitor, one that does not have an account and is not logged in, it might display the latest special offers. For a logged in returning customer, one that is a frequent buyer, the page might need to show special discounted prices applicable just to these kinds of users. For an administrator of the web page, it might need to display some tools to allow editing the list of products. Even if we’re talking about the same page, there shouldn’t be a single big user story treating all the above situations. We can easily split the story into three smaller ones, each type of users handled separately.
Consider a web application that periodically needs to import some accounting data from different places. One source might be an external database, another could be a RESTful API, while other sources might be Excel files. All this data will end up in the same place inside your web application under a common representation. There is no question that you should be handling this feature with different user stories, one for each data source.
Lastly, consider a lending web application where a person applies for a loan. The system could grant or reject the request based on many, many variables: how long has it been since the person took their last job, what is their monthly net income, do they have other ongoing loans, have they ever been late to repay previous loans, etc. Taking into account all these variables at once while developing such a feature, you’re bound to painting yourself into a corner, with a codebase so convoluted that even you won’t be able to make sense of it after a while. You can avoid all that hassle by taking baby steps: split the user stories such that each business rule is introduced gradually, one rule per story. Test driven development can help you in this regard, too. The process of “red-green-refactor” coupled with introducing one concept at a time will lead to cleaner code, backed by tests.
Now you can see how the INVEST model can be used to decipher the why, the when and the how of splitting stories. You can apply an easy rule of splitting user stories, not that much different from the “divide et impera” mantra. You’ve seen a few practical examples of how stories can be split by the variations in the user interface, in the business rules and in the data sources.
Having small stories is beneficial to your project, not because others say so, but because it is a must for a constant flow of new features and for getting early feedback on your work. More tips and tricks about splitting stories and avoiding the curse of “almost done” features can be found in this article.
Let us know in the comments if you would like to share your examples on this topic.