Apple Brook Consulting® (ABC)

Lettuce (pun intended) imagine the layers of a burger as layers in our application development stack. Pretend we’re looking to add a product feature to change the content of an email after it has been sent to our customers. We have a UI layer that you can interact with and make the changes in, the middle-tier layer that does some data transformation, a security layer that provides defense of our customer data through a signed in account, and a database layer that stores and retrieves the changes we make to our customer emails. How do we write stories that encompass a small slice (or bite) of each of these layers so that they are all usable faster?

The diagram helps to explain it and I will get into more detail as we progress through this post. We would rather be normal eaters at our local fast food burger joints and take bites through the layers, enjoying all the flavors together over pulling our lovely flame-broiled burger apart (and making more of a mess). Cleanliness aside, what are some other benefits to vertical slicing?

 

Deliver Customer Valuable Stories

An example we often hear has something to do with horizontal slices delivering a non-dynamic UI where we can access email fields to change but they aren’t saved, a middle tier level that translates changes but can’t be accessed from the UI, or a database table that can’t save or retrieve the email changes. If we delivered any one of those pieces alone, the customer could not use them, so why would we write stories that way?

Usually it has to do with the way our teams are formed based on skills. They are componentized with a UI team, a middle tier team, a database team, a security team etc. Highly specialized teams seem like a good idea until we see how many dependencies there are between teams. As we add more teams working on separate components of the product, these dependencies become more pronounced and harder to work around.

If we look to split our component teams into feature teams, we can deliver a vertical slice. This could look like being able to edit (in the UI), transform (middle-tier) and save (in the database) a field in a sent email, while signed in to your account (security). Then we build on additional dynamic fields to that slice in subsequent stories (edit, transform, save body content, images, etc.). This way, we can deliver value to the customer immediately. Will a customer get value from one field of information they can edit and save? Yes. Is it a lot of value? Maybe. But, is it more value than an unusable UI, middle tier, or database with no security? Yes. Can we learn from it? Yes.

For example, let’s say each story takes the team one sprint. If we horizontally slice our functionality (UI, middle tier, security, and database layers in separate stories) it would take us four sprints to deliver end-to-end functionality. Vertical slicing the same scope of work would theoretically take us one sprint for each story, too, but we would get end-to-end usable functionality at the end of each sprint. Both ways it’s multiple stories, but the value and usability delivered after each sprint is vastly different.

Speed to validate

Another argument against vertical slicing is that we don’t release after every sprint, so who cares if we deliver usable customer value each sprint? Well, if we have to do a quick release for competitive advantage I would sure hope we had vertically sliced.

But did you notice how in the introduction I said speed to validate, not speed to the customer? We can still use vertically sliced stories and features to validate our product direction even if we do not release them into production. We may have internal customers that can view our finished stories, we can release a beta to other customers to preview, or we can use the code to prototype and perform usability, accessibility, performance, or load tests to name a few.

By having end-to-end testable functionality sooner, we can better understand if we’re going down the right path faster. See the last paragraph of the previous section – the ability to validate after one sprint versus many – speed! By having a better understanding of how our stories work and how our product functions more quickly, we decrease our risk of building the wrong thing or building it wrong.

If we do release every sprint or every other sprint, we are delivering useable functionality much quicker which can give us an advantage in the market sooner, too.

Trim the tail

If we find we’re going down the wrong path, it is much easier to stop with vertically sliced stories. I can decide to forgo editing the body content field and trim the product tail on development with the last fully functional, vertically sliced story focusing on the email subject line. If I have a horizontal slice, I may already have a full UI, middle tier, or database but not all three working together. So in order to deliver value, I need to finish all pieces of all three. If something is not needed, like the email body content, that is waste.

By waste I do not mean that the work done was poor. I mean that if we are not going to use it or don’t need it, it was wasted effort because we could have been working on something more valuable – maybe changing and saving an image. It’s a crappy feeling to develop something that is not going to be used. It is even crappier if we implement it anyway and have to maintain it when it’s not doing our product or our systems any good.

Testing efficiency

I’m not a tester, but when I think of trying to test horizontally sliced story it suddenly seems a lot harder. I can test and entire UI that doesn’t do anything (does it look right?), then test an entire middle tier that isn’t hooked up to data (should it function – fake data?), or a database that is not dynamic or receiving processed data from anywhere (syntax?). And then after they are all put together I can end-to-end test and see if they integrate and work like the above example. It seems like a duplicate effort to me, and that is wasted effort.

In a vertically sliced story I can test end-to-end if the field passes through the middle tier and saves in the database. I edited my subject line, it was passed through the middle tier and it is now saved in the database and I can retrieve it when needed using my secure account.

In addition, a large horizontal slice will probably take us most of the sprint to complete so we will be more likely to have our testing effort carry over. Not what we’re looking for with faster delivery and customer validation.

Team swarming

A final benefit that stands out with vertical slicing is team swarming. If we have a piece of work that numerous team members can work on together (think our subject line with UI, middle-tier, and database experts), we will finish it faster. The team will work together and things will integrate better. They will have a better idea of how to test it. And if they’re working together on a story and talking about it, they will each understand what the other is doing and what they need so we can start to build our cross functionality of skills between members. This will make us even more of a feature team than a component team.

If we have people working on stories together, our WIP will also decrease and our story flow efficiency will increase. In other words, we will start less and finish more. I would rather have one or two done stories than five partway done stories at the end of a sprint. It’s more efficient, but more important is that it is more effective.

But…

Alright here is the part for all my dissenters out there. I know this is hard. Like, really hard. I know teams cannot be changed overnight. I know that there need to be good infrastructures and skills in place to support this. I know we cannot flip a switch and do this. But we can make progress.

Use your head and figure out what works for your team and your company. Can’t hit the entire vertical slice? How about two pieces of it? Three? Have to keep a component team? Figure out how to slice around them. Team members have limited skills? Start pairing and slicing vertically on one story a sprint and then increase to two after a few sprints.

The thing is, there is an opportunity cost for not vertically slicing. We can either pay it at the beginning by taking more time to split stories and maybe doing some extra work, or we can pay it later by increased testing effort and potentially wasted features and effort. It’s always cheaper to pay it in the beginning. Like all of Agile – this is a guideline. It’s a loose enough defined practice that you can make it fit where you are now and where you want to be next sprint, in three sprints, or next year. Now, take a bite (byte) of that hamburger!