One of the challenges I continually observe 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).
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.
e.g. steps to checkout at an online store; enter billing address, enter shipping, address, enter payment information, etc.
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
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:
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
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!