In my previous post, I shared an experience I had with a scrum team in which vertical slicing made the difference between compliance with federal regulators. Below is a quick overview of why this approach is preferred and some simple strategies for splitting stories into small slices.

Horizontal vs. Vertical Slices

The design process is a series of steps that engineers follow to come up with a solution to a problem. Solving small problems is easier than solving large ones, so decomposing a large problem into a set of smaller problems is part of the engineering design process.

Horizontal Slices

The traditional approach to building a big feature was to decompose it into the work that had to be done at architectural layers. For a web service, we might break a feature down into the database components, the server components, and the client components. Often specialists in these areas would build their piece of the architecture separately, and then we would have an integration phase at the end where we would put them all together and test them to make sure they worked as expected. While this makes sense logically, and allows us to develop high expertise in one of the architectural layers, it tended to have a very slow feedback loop depending on the size of the feature, since we’re waiting for everyone to be done with their separate piece to integrate and make sure it works. The term “horizontal slicing” refers to using this architectural layer approach as the primary method of decomposition of big features.

Vertical Slices

In order to speed up the feedback loop, we take a large feature and break it up into several small pieces that slice through each of the architectural layers. It is possible to break down almost any feature into slices that take a couple of days at most to get all of the pieces built, integrated, and tested. Each slice is comprised of any work needed to be done in an architectural layer as well as any testing and integration that may need to be done to make it ready to release. In other words, the definition of done for each story includes all the work to make it potentially shippable.

Four techniques for vertical slicing

There are many different ways to vertically slice a user story. Here I show you four that cover most scenarios: Vague Terms, Conjunctions, Acceptance Criteria, and Workflow Steps.

Vague Terms

Sometimes we get user stories containing terms that are somewhat vague, which is ok since user stories are supposed to be “Negotiable” (see Bill Wake’s INVEST acronym). Vague terms often lead to possible vertical slices.

Example Story: “As a music listener, I want the device to store several hours of songs, so that I can listen to music when I don’t have cell service.”

Your first reaction to this story might be, “What do you mean by ‘several’?” The term provides an opportunity to slice by using an incremental approach. For example we might get the following slices by getting very specific:

Allow for storage of data equivalent to 10 hours of music
Store the 10 most recently played albums

Conjunctions

Conjunctions are words that are connectors: AND, OR, WHEN, IF, BUT for example. When there is a conjunction in a user story, it creates obvious opportunities to create a vertical slice.

Example Story: “As a music listener, I want the device to store several hours of songs and their identifying data, so that I can listen to music when I don’t have cell service.”

Notice that the “I want” statement of this user story has two parts: save the songs AND their identifying data. These are really easy to split into two slices:

Store the 10 most recently played albums
Store the identifying data associated with the stored music

Acceptance Criteria

Example Story: “As a music listener, I want create playlists so that I can hear songs that belong together according to my preferences.”

Now look at the acceptance criteria that the team building this story came up with:

Group songs in a playlist
Select order of songs in playlists
Allow songs to appear on multiple playlists

Notice that each of these criteria could become its own vertical slice, or in some cases multiple slices.

Workflow Steps

Another way to split stories is by thinking about how a user will interact with the system, and building one little piece of that interaction at a time.

Example Story: “As a music listener, I want share playlists with my friends so that they can hear songs that belong together according to my preferences.”

We can break this user story into several workflow steps, each of which could be developed one at a time:

Create playlists
Group songs in a playlist
Select order of songs in playlists
Allow songs to appear on multiple playlists
Create friends list
Assign songs to playlist
Friends receive notification that I have shared a playlist
Friends receive link to sample songs in the playlist
Friends receive option to buy songs in the playlist

The advantages of vertical slices

The smaller slices are much easier to understand, so there is greater likelihood of reaching consensus among team members.
Estimates are generally more accurate for small stories.
When we decompose into small pieces, we often realize that not every single piece is really required by the user.
Smaller slices give us a faster feedback loop – we find defects in design, usability, code, and integration.
People with specialized skills are not waiting while work is done in a previous step – with small slices, work is constantly flowing through the system.
Small slices allow the team to get small wins on an almost daily basis, leading to greater engagement.
Daily scrums become far more interesting and useful.

Conclusion

There are many good reasons why vertical slicing is preferred, not the least of which is to shorten the feedback loop. Sometimes the reason is because priorities change, communication breaks down, the market dries up, or the government regulators move the deadline date. Whatever the reason, vertically slicing stories with a robust definition of done allows the team to welcome changes at any point in the development cycle.