Agile Vertical Slicing: The Cake is a Lie

Do your software releases fail to meet stakeholder expectations? The root cause may have more to do with slicing than expected.

Slicing

Slicing in this context refers to how we decompose work into tasks. We typically think about application architecture in layers. Many software design patterns will refer to these layers differently, but generally speaking, there are three generic segments.

1. View Layer: Visuals and interactions with the user
2. Logic Layers: Business and application logic that manipulates the data
3. Database Layer: Permanent data storage

If you think of an application comprised of these three layers, we have two main methods available to generate manageable chunks of work. We can slice horizontally so that our work items fit within a single layer, or we can slice vertically so that work items cover all three layers.

Vertical Slice vs. Horizontal Slice

Horizontal Stories

Horizontal user stories will align with the architecture layers. Since each piece of functionality will cross multiple layers, you’ll end up with multiple items covering what would be a single ask from the user’s perspective.

When you think about horizontal slices, you’ll notice that you’re no longer thinking about the user. Instead, you’re thinking about it from an application perspective. Stories like this will not facilitate conversations between users and the Scrum Team. In fact, they are more likely to alienate non-technical users because they’ll quickly become steeped in specialized jargon.

Horizontal stories will also be more challenging from a backlog refinement perspective with additional Product Backlog Items and dependencies.

Another con of horizontal stories is that they don’t meet several of the six INVEST criteria for good user stories.

The stories are dependent. Even if you can make an argument that the seven layers are independent, the last story to put them all together depends on the previous seven.

The stories deliver no value from a customer perspective. Delivery of even a tiny bit of functional software is better than just a promise that the CRUD operations are in place.

It’s questionable whether horizontal stories are testable. In some cases, you would be able to test the individual slices, but you’ll have to do integration testing again once you incorporate all of the various components.

Splitting work this way is rooted in traditional project management and teams siloed by specialty. Horizontal stories encourage siloing work and knowledge. Harry is comfortable doing database work, so he’ll pick up all of those work items. Then Ron and Hermione are left trying to support this code while Harry is out on vacation.

Vertical Stories

Vertical stories slice through all of the layers of the architecture and provide a small piece of functionality—one more step toward a finished product. Sticking with the dip metaphor, this is equivalent to a chip with all seven layers, the ultimate goal of a seven-layer dip.

Vertical slice test coverage is more comprehensive than a horizontal slice because we can account for all acceptance criteria in a single pass. We also circumvent the need for integration testing as multiple components aren’t developed independently of each other. Once QA is complete, we have something that adds value from the customer’s perspective.

It can be hard to balance slicing the work so that it is small enough to complete within a Sprint, covers all application layers, and provides value to the customer. Similarly, it can be hard to dip your chip deep enough to get all layers without overburdening the chip.

Vertical slices encourage knowledge-sharing, skill-building, and cross-functional team formation. Taking ownership of a vertical slice of the work increases the odds of one person working across all the architecture levels. If they lack the skills to complete the work themselves, they might pair with someone else on the team. Even if they choose to delegate a specific part of the work to a more skilled team member, they’re more familiar with the functionality because all the discussions have been holistic and not segregated by technology.

If Harry is on vacation, it is more likely that Ron and Hermione are at least familiar with some aspect of the work and will be able to support it more easily.

The Cake is a Lie

I’ve seen the vertical vs. horizontal debate described with metaphors ranging from cake to tiramisu. I feel obligated to offer my own comparison, but before we get into that, let’s discuss why the cake metaphor is weak.

The argument contends that vertical slices provide more customer value than horizontal slices. Applying that to the cake metaphor, almost no one will turn down a vertical piece of cake, nor would they feel slighted by a horizontal layer.

For a better metaphor, consider the 7-layer dip example from above. This dip usually consists of the following layers: refried beans, sour cream, guacamole, salsa, cheese, green onions, and tomatoes. When layered together, it makes a fantastic heap for dipping chips.

Now imagine that you’ve ordered said dip, but what the waiter brings you is just the layer of refried beans. No one will be happy with a pile of gross beans, especially not when they’re craving a delicious chip companion.

When the waiter tries to explain how the kitchen works and ensure you that the other layers will be out shortly, you will wonder if you’ve stepped into the twilight zone.

Why Vertical Slice?

Just like no self-respecting Mexican dip connoisseur would settle for just the bean layer, stakeholders appreciate the delivery of working software.

According to Cohn, vertical slices have the additional benefit of helping us prevent last-minute bugs. When working on a larger piece of functionality sliced horizontally, it’s common to discover bugs during integration tests when we fit all of the disparate components together. The team reduces the risk with smaller vertical slices where they develop the functionality across multiple layers in tandem and test each smaller piece.

One last benefit of vertical slices is improved feedback loops. The faster that stakeholders can use the functionality, the quicker we’ll get feedback. The faster we get feedback, the early we can change direction if necessary. Thus we improve our chances of building the right thing.

Works Consulted

• User Stories Applied: For Agile Software Development
• The Humanizing Work Guide to Splitting User Stories
• The Magic of Tiramisu: How Vertical Slicing Helps Agile Teams Deliver More Value
• 7 Layer Dip
• MVC: Model, View, Controller
• The Model-View-ViewModel Pattern
• Create and Implement 3-Tier Architecture in ASP.Net

TLDR

If your ‘done’ stories aren’t delivering value to your customer, you might be slicing your work wrong. Consider taking vertical slices that include all layers of the application functionality so that the stakeholders receive something tangible.