In agile, one of the most crucial concepts when writing User Stories is “slicing the cake.” Whenever I train Scrum, this is one of the two most important things that people must understand when adopting agile (the other is the inverted triple constraint). So, what does it mean to “slice the cake,” and how do you do it?
User Stories
What the heck are User Stories? In a nutshell, User Stories are statements of need written from the user’s perspective. They include the who, what, and why of the Story. Along with accompanying Acceptance Criteria, the combination represents a fully defined requirement.
Horizontal System Layers
An example of a horizontal User Story might be:
As a developer,
I want to have an API service available,
So that I can send and receive data in the system
The first problem with this User Story is that it’s written from an improper perspective. You should always write User Stories from the customer or end-user’s viewpoint – not a developer’s; this is a technical task disguised as a User Story.
Where is the value proposition in this User Story? There isn’t one, and every User Story (with few exceptions) should produce demonstratable business value.
Vertical Slicing
In agile, the preference is to build smaller pieces of functionality that slice through all the horizontal system layers. It could be as simple as one piece of data on one screen that pulls from a database. The point is that it must traverse all levels and be fully working from end to end.
I often get a lot of pushback on vertical slicing, especially from people involved in traditional software development for most of their careers. They are uncomfortable with not knowing everything and having all designs determined upfront.
Another fundamental tenet of agile is that the best architectures and designs “emerge” during the agile process (see the Agile Manifesto). Yes, this means there will be refactoring, but that’s okay! I know it’s a challenging change to adjust to, but it’s essential to succeed with agile.
Here’s an example of a vertical slice:
As a new user,
I want to create an account in the system,
So that I can use the application
As you can see, this is a relatively small story split along operational lines (aka CRUD – Create, Read, Update, Delete).
Can you see how this would slice through many different system layers?
The tasks to build this User Story might look like this:
- Create a database for the system
- Set up a table for user information specified in the Acceptance Criteria
- Build a screen that displays the available user fields required for an account
- Connect the screen to the database
- Provide a method for the user to save their data
- Show a “success” confirmation message
The work to develop this User Story is much smaller than the work to build a whole database, do all the data validation and error handling, security, permissions, etc.
By taking only a small, discrete piece of functionality, your team can develop and test it within a Sprint, and show it to real customers in the Sprint Review to gather feedback. Remember, too, that each increment builds on the previous ones, and the product will emerge over time.
Final Thoughts
Writing and slicing User Stories is deceptively simple. Like Scrum, it’s “easy to understand but difficult to master.” The first step is to ensure you write all your stories from a user’s perspective and that they slice through all the horizontal system layers. Once you have this down, you can move on to more advanced splitting concepts – so long as you still slice the cake vertically.
Have you run into the problem of horizontal story splitting? If so, how did you deal with it? Have you fallen into this trap yourself? I would love to hear any stories you have to share about this topic in the comments below!