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).

During one coaching engagement, I received feedback that the team was frustrated because their new Product Owner wasn’t being effective.  The acceptance criteria in the stories were vague and insufficient. The team had previously been operating without a Product Owner so the initiative was being led by what could be considered an architect or technical lead.

I joined one of the team’s backlog refinement sessions to observe firsthand what was happening.  It was readily apparent that the Product Owner was indeed not being effective, not due to incompetence, but because the stories in the team’s backlog were not vertically sliced.  The team was working on an initiative that involved significant technical complexity. The team had 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 was working with new technology so they were heavily dependent upon the architect/technical lead to guide them in how to implement the tasks. The new Product Owner had substantial business expertise but because the stories were structured horizontally and the Product Owner could not write detailed technical specifications, the perception was that the Product Owner was not competent.

Working with the Product Owner, we applied some of the common story slicing patterns 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, I have observed 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!

Webinar: Vertical Story Slicing Takes the Cake

This blog, originally posted in April 2018, was updated in January 2022.