User Stories: Making the Vertical Slice

Incremental software development entails delivering finished components of the whole in parts. It allows you to stagger the release of features which are of utmost value to customers.

Iterative software development allows for instant feedback at multiple levels of the product development process. For example, for developing a food delivery app the customer was first presented with a wireframe version of the app and feedback was taken. The subsequent steps followed the same pattern where feedback was taken and incorporated.

The Agile methodology incorporates both incremental and iterative product development processes.

One of the challenges we continually observe is that Scrum teams struggle with in their Agile adoption is the concept of vertical story slicing.

As described by Wikipedia a vertical slice “refers to a cross-sectional slice through the layers that form the structure of the software code base.” For example, a simple vertical slice would encompass the data access layer, the business logic layer (a.k.a. middleware layer) and the user interface layer. A vertically sliced story should also encompass the testing that corresponds to the functionality being delivered.

Vertical slicing is intimidating to teams when they first experiment with it. Even teams that understand it conceptually often struggle with decomposing their stories small enough while still achieving a vertical slice. Consequently, teams revert back to their old habits of creating user stories that are horizontally sliced.

For example, they’ll define one story to create a web service, another story to create a database table, and yet another story for testing. These so-called stories, are actually tasks. Horizontal stories typically do not meet a well-formed story structure of “As a <role>, I want <functionality>, so that I can achieve <value/outcome>” and they don’t meet the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).

At times team is frustrated because their new Product Owner is not effective. The acceptance criteria in the stories are vague and insufficient. Most of the initiative are led by what could be considered an architect or technical lead.

If you join such team’s backlog refinement sessions to observe firsthand what is happening, it might be readily apparent that the Product Owner isindeed not being effective, not due to incompetence, but because the stories in the team’s backlog are not vertically sliced. The team is working on an initiative that involved significant technical complexity. The team has become accustomed to working under the guidance of the architect/technical lead who was creating horizontally sliced stories (in reality, tasks). Furthermore, the development team is working with new technology so they are heavily dependent upon the architect/technical lead to guide them in how to implement the tasks. The new Product Owner hads substantial business expertise but because the stories are structured horizontally and the Product Owner could not write detailed technical specifications, the perception was that the Product Owner was not competent.

Some of the common story slicing patterns are listed below to define vertically sliced features and stories for “building a data dashboard and launching detailed reports from the dashboard.”

Patterns

• Workflow steps

e.g. steps to checkout at an online store; enter billing address, enter shipping, address, enter payment information, etc

• Simple/Complex

e.g. ship to single address vs. ships to multiple locations

• Business Rule Variations

e.g. process transactions in states that don’t collect sales tax vs. states that do

• Major effort

e.g. add to shopping cart, add to wishlist, etc.

• Operations (Create, Read, Update, Delete)

e.g. Add item to cart, view cart, update items in cart, remove item from cart

• Variations in Data

e.g. show shipping dates for Amazon Prime vs. non-Amazon Prime customer

• Variations in Interfaces

e.g. mobile, tablet, PC

Defer System Qualities

e.g. performance, logging, etc.

• Happy vs. Unhappy Path

e.g. enter credit card info, credit card is expired

Here are some abstracted examples (so as to not disclose any proprietary details) of how we translated some horizontally sliced stories to vertical slices:

Horizontal

• Modify universe to add data element X to SQL query
• Build a table to store dates and date ranges
• Create a job to pull data into a database
• Convert data to use new data model
• Create a new endpoint on the existing web service to return a static list of filter options

Vertical

• Show business metric A in a pie chart with prior year annual totals
• Show business metric A in a pie chart with current year annual totals
• Show business metric A in a line graph with prior year totals
• Show business metric A in a line graph with current year totals
• Report A — Display demographics section
• Report A — Display business metric A line item details
• Report A — Filter by Date
• Report A — Filter by Location

In the above vertically sliced examples, the Variations in Interfaces pattern was used to slice stories into pie charts and line graphs. These stories were further decomposed using the Variations in Data pattern to delineate between prior year and current year as well as the different sections of Report A. Another pattern of splitting by Major Effort was used to define filtering capabilities in Report A by Date and Location.

Vertical slicing allows teams to demonstrate incremental progress thereby increasing transparency. Just like no self-respecting dessert lover would accept a horizontal slice of cake that might be missing the top layer of icing or the yummy filling in the middle, stakeholders appreciate seeing a pie chart or the first section of a report in a Sprint Review versus fragments of Java code for a web service.

Unfortunately, there is resistance to vertical slicing by teams because they are more concerned about management optics. It’s easier to “hide” the lack of progress when stories are more technical in nature or there are a lot of stories (that are really tasks). Even if the team falls short on its commitment, they still appear to have successfully delivered the bulk of their work in that sprint. While their concern is understandable if the organization’s leadership is too heavily focused on metrics that don’t emphasize value delivery, for a team to be truly Agile, they must be willing to be transparent, experiment, sometimes fail, inspect, and adapt. Any team that doesn’t experiment, doesn’t occasionally fail and most importantly, does not deliver tangible value, is not Agile. If your team is struggling to define acceptance criteria, it cannot effectively test a story, or it cannot validate that it meets the definition of done, evaluate how your stories are sliced. Allow your team time to experiment and practice with vertical slicing and pretty soon your team’s stories will take the cake!

For example, I want to build a site that sells shoes.

My features might be:

Display informative Home screen
User Registration
User Login
Display Products
Display Shopping Cart
Add products to Shopping Cart

And then, User stories would be developed off those:

Display informative Home screen
- As a User, I want to access the Home scree, so that I can enter the website
- As a user, I want to be able to see specials, so that I can see the current deals

User Registration
- As a user, I need to be able to register as a new user, so that I can have more access to the site
- As a user, I want to be able to register with my Google account

User Login
- As a user, I need to be able to login with my username/password, to gain access to the site
- As a user, I want to be able to login with my Google account, to gain access to the site
Display Products
-

Display Shopping Cart
-
Add products to Shopping Cart
-

etc etc.