How Do You Like To Eat Your Cake? A View on Vertical Slicing
Let’s say you went to a cake shop and you were served a slice of cake that consists of 5 fruit flavors. If you are only given a bite to eat, how would you slice your cake? Normally, people would slice it vertically from top to down, to be able to taste all the flavors in one bite, so that you maximize the value of that one bite. That makes sense when eating a slice of cake, it makes sense when running complex projects.
In my journey of transforming organizations to Agile, I have seen different ways on how the teams split epics into user stories. For organizations that practiced the Waterfall model, they would practice slicing the work by layers, such as the User Interface layer, Business layer, Security layer, and Data layer. So, what’s wrong with this? Let me give you a real-life scenario.
A CASE STUDY
There was an insurance system project that was estimated to be completed in 7 months for the development of the whole system. That 7 month excludes the time done for the requirements gathering, systems design, and the estimation process. The way the system was developed was starting with the user interface designs, then the business layer and security layer. Then came the data layer. It took the team 7 months to be able to show the customers the working features of the system. With the amount of time that passed before submitting a working feature, it poses different risks. For example, what if the customers changed their mind on the features? What is the overall direction of the company has changed in that period?
The way this Team sliced the work was horizontal. They developed what was needed to deliver the whole system, but they did not do it in a way for customers to feel their value for what they pay for as early as possible. It took the Team 7 months to be able go-live and it didn’t benefit the customers to start earning revenue from their investment. If they developed the system feature by feature (vertically), then it could have given the customers something to look forward to every time they did a demo. Not just to be able to see the initial features working, but they can ask for those working feature to be deployed to the production environment and start earning revenue from it.
Another experience that most of us will be able to relate to is condominium developers. Contractors will not build the building by creating all the floors, then the rooms, then put all the flooring, bathroom fixtures all at the same time. They would build the ground floor first and complete it before building the 2ndfloor, then the 3rdfloor, so on and so forth. When the ground floor is completed, they would rent it out as commercial space, for them to start earning revenue while the rest of the building is being constructed. The money collected from the commercial space rentals can be used to fund the rest of the construction. Every floor that is completed would mean that it can be sold or rented out already.
ANOTHER CASE STUDY
One more experience I saw before was related to getting paid up for a project. The customer asked this freelancer to create an inventory system to ease the burden of manual tracking and recording. The freelancer was given 2 options for the payment. The first option was to complete the whole inventory system in 6 months and the customer will pay him the full $12,000 after 6 months. While the 2ndoption was to deliver each part every month and the customer will pay him $2,000 every month. If you were in the position of the freelancer, what option will you choose?
Of course, you will choose the second option, to be paid every month. That way, you already start getting the payment for what you have worked for. And you can also use the money in other investments to make it even grower larger or just simply enjoy the fruits of your labor. Getting paid every month of the partial amount gave more value to the freelancer. At the same time, the value was given to the customer since he was already able to use some of the features right away such as adding of inventory, updating of inventory, deleting of inventory, dashboards, etc. Although the system is not yet fully complete, it already helped ease the daily manual labor his company is currently doing and lessened the instances of human error.
In the Agile world, we follow the INVEST acronym as a guide in splitting epics into stories. It enables us to focus on small tasks at a time and get it done quicker and put in more quality. We can use the same in our daily work. The INVEST acronyms stand for
I – ndependent
When we create our stories, let us try to make them as independent as possible from each other. This way, it allows the Team to work with the stories in any order and have more flexibility in the prioritization of each story. The fewer dependencies, the better.
N – egotiable
A story tells us what is desired by the customers, and it starts a conversation about what the customer wants. The final story is a result of a collaboration and negotiation between the customer and whoever is going to work on the story.
V- aluable or V– ertical
For each story, we need to think of what value it can bring. When we say value, it can be a functional or a non-functional value. The value can be for the customer or the actual user of the story.
A story is something that can be estimated so that it will help in prioritizing it. If you are not able to estimate a story, it may mean that you need to further split the story and give it more clarity.
If you are not able to estimate a story, it may mean that further splitting is needed. The smaller the story, the easier for it to estimate and it will have lesser dependencies. Some may ask, how small should a story be? It depends. Some can be completed in 1-2 days, some in 3-4 days.
To know that we are delivering the right quality, we need to make sure that stories can be tested. By running them through testing, we can be confident that the requirement is delivered based on the acceptance criteria.
Just like the slice of the cake, we want to get the value in every bite. Who doesn’t want value as early as we can get it? Don’t you want the same?
Stanley has more than 15 years working in the IT industry, with expertise and focus on Agile coaching and transformation, at the same time managing programs and project teams. During these years of experience, he has proven himself in guiding people and processes to deliver quality solutions. He focuses on the team dynamic and delivery to motivate the organization.
Connect with Stanley Ang on LinkedIn