Gone Are The Days Of Vertically Sliced Stories

While working in an agile development team be it any role Business Analyst, Scrum Master, Product Owner or even Developer, we all would have heard how and why user stories must be vertically sliced. Wikipedia describes a vertical slice as: 
 

 “... a cross-sectional slice through the layers that form the structure of the software codebase. For example, a simple vertical slice would encompass the data access layer, the business logic layer, and the user interface layer”.       Below is the diagram we’ve seen with this definition, where the story is sliced vertically across different layers of the application. 

This was true a few years back when multiple services and the UI layer were deployed as a single artifact and, most of the time, developed by a single team. But with microservices architecture and an increase in the number of channels that an API can be consumed by, having a vertically sliced story from persistence to the UI layer is impossible

Let's look at an example of a video streaming service. Let’s call it Binging. In the past, to display the average ratings for videos we would have written this story:

As a user of Binging

I want to see the average rating for each video

So that I can decide which video to watch.

This story would have needed to cover pulling the ratings from the database, calculating the average, and displaying it on the UI. But, in the current world, we don’t know which channels are going to display ratings and in which format. For example, how the ratings are displayed on the web will be different from how they are displayed on the Roku app and the android app might not even display the ratings. 

Let's go a little deeper into this example. The high-level architecture of Binging service would look something like this:



And the team structure would replicate the above architecture:




Hence, it is impossible to have that one story to display the average ratings for the videos. We will have to have one story for the “Ratings” service and one for each channel consuming that service. Following are some of the examples:
 

1. As a consumer of Ratings service
   I want to get the average rating for the list of videos
   So that I can display it to my users
2. As a user of Binging Roku app
   I want to see the average rating for all the videos
   So that I can decide which video to watch
3. As a user of Binging website
   I want to see the average rating for a particular video
   So that I can compare it with other videos 

The question here will be, are we increasing the effort and time to deliver the feature of displaying the average ratings? 

I would say no because the number of channels that the ratings are now displayed on has increased. Plus, we’ve got the flexibility of displaying ratings in different formats on different channels. For example, the ratings on the Roku app can be displayed with the listing of videos. But, on the website, the ratings can be displayed on the video details page. Along with this flexibility of the display, it also reduces the new feature rollout time. For example, “Sort by Ratings” can be quickly added on any channel without making any changes to the “Ratings” service.

Additionally, the “Ratings” service can be consumed for analytics, reporting, market research, etc. For example, we can answer questions like ‘which are the highest rated videos?’, ‘which videos are rated high by which demographics?’ and  ‘which videos are rated high or low in which countries?’. These questions can be answered by the “Ratings” service without impacting any of the channels.

To summarise, the concept of vertically sliced stories is still valid, but the size of the slice has changed. If we consider each channel and microservice as a product, then stories within those products must be vertically sliced. As in the above example, the story in Ratings service will pull all the ratings from the data store, calculate the average, and emit the average rating for a given video or list of videos. The story for the web channel will make a call to Ratings service and display the average rating for each video in an intuitive and user-friendly format.   

Each of these stories is vertically sliced, providing a business value of its own and can be tested and deployed independently. 

One important thing here to remember is that all the PODs should understand and agree on their Product Boundaries. This will help in the end to end feature prioritization and planning. It will be slightly difficult and challenging when you are starting to move from a monolithic application to Microservices architecture but once all the PODs understand the responsibilities of their respective products, it becomes business as usual.



In the days of the monolithic applications, vertically sliced stories were compared to the above slice of cake, where no one would like to have horizontal layers of a cake. One would prefer to eat a vertical slice with all the layers. But with the evolution of microservices platforms and increasing channels, we will have to think differently, like providing the cake base, frosting, whipped cream and sprinkles separately so that we can serve

cupcakes...

Or ice cream sundaes..

 

Or a completely new dessert to our customers...