Now we tackle the second step: create user stories based on vertical slice. Do you want your team members to have meaningful tasks of which they feel proud? And do you want to keep your stakeholders happy by showing them results? If yes, the solution is right here!
What is a vertical slice?
Most software application features have three architectural layers: user interface or front-end, API/logic or back-end, and database. Some apps are more complicated and have extra layers while some may be much simpler. The bottom line is that every app has several layers. Imagine a cheesecake that consists of multiple layers.
In any project management methodology, you break down development project to smaller, manageable pieces. Each piece is called an activity, a task, or a user story. The latter is the Scrum term of course. I will call it a story to keep it short.
There are two ways to create stories:
- Horizontal slicing: in this method, you cut the cake horizontally. Each story is either a UI work, or a back-end development. When you finish a story, the outcome may be a UI mock-up that doesn’t have any logic or data saving capability. Or you will have some progress on back-end side such as an API development, database design, etc.
- Vertical slicing: how do you eat your cheesecake? You slice it vertically to ensure you get a part of each layer. Yes, I assumed you liked it that way! In an application development, a vertical slice requires development on all the layers: UI, back-end, and database. The outcome is a new feature that has an independent value for users. Although it might be a small one, the feature is fully functional.
For example, if the new feature is ordering food online, its UI part will allow users to add food items while the back-end API will update database accordingly. A vertical slice includes both of them. In addition to order feature, you may want to add an edit feature so users can modify their orders. This feature is another vertical slice. If you opt to create two stories that one consists of order and edit UI and the other one takes care of both back-end changes, you will have horizontal slicing.
In simple words, vertical slice makes a small but fully functional change rather than a big change on UI or back-end alone. As a result, users can actually use the feature.
Why stakeholders love vertical slice?
Users love vertically sliced stories. Why? They can see new features and actually use them. Compare it to a sole change on back-end side. If you talk to developers and technical folks, they may understand what you have done. Otherwise, you won’t have anything tangible to present. Even a UI that doesn’t have any logic or data saving is not as effective as a fully functional feature.
Not surprisingly, stakeholders are truly in love with vertically sliced stories. It’s a true love. A demo of a functional feature makes stakeholders happy and assured. It’s like a little kid finding her mother after being lost in a crowded shopping mall. When project sponsors and clients see your projects move ahead and deliver results, they will feel confident about your capabilities and also the methodology you have chosen. A vertically-sliced story delivers incremental results. Don’t you need to show results as frequently as posssible?
It doesn’t take a genius to know if you demonstrate working features, stakeholders will support project. You can also share your success with the development team. Every one is happy. And you can move forward implementing Agile.
One more thing: developers love presenting new functional features. They can also show the results of their efforts and be proud of their achievements. Do you remember in Part I we discussed Maslow’s analysis of human needs? Vertical slice satisfies Self-esteem need.
Conversely if you jut show back-end changes, that most clients and project sponsors don’t get anything out of it, or present incomplete features, stakeholders will feel agitated: “Is this project coming along? Can we meet the deadlines? We don’t have anything fully baked to show to our senior managers yet.”
And do you know what is next? Probably they will ask you to drop Agile and roll back to the old methodology so you can finish this project asap. “This is a high priority. Please do it based on our familiar processes. We will do Agile later.”
That’s why all user stories in Agile should be independent. Each story should deliver some kind of value to your users. Cut the work vertically so you can regularly deliver a little piece of complete functionality. At the end of each Sprint, you will have at least a demonstrable feature to present to sponsors or clients. Your team members will be proud of what they have done and your stakeholder will gain assurance and confidence in your ability. These are exactly what you need to fuel the rest of your journey toward Agile.
In the third part, we will discuss the thirst important step, providing feedback.
What do you think? Go down and comment about your experiences. Did you have a similar experience?