Vertical user stories imply that all necessary work in the database, service and UI layers will be testable and verified by the user. In fact, any story written by an end-user is typically a perfect vertical story that will result in business value delivery. So what is the big deal? Most agile teams break their stories down into horizontal slices that independently provide no business value. Vertical stories are keystone to reducing time market while tracing financial impact end to end, which is kind of the whole business case for investing in agile adoption in the first place.
So when do vertical stories become not so vertical anymore? Top reasons include:
1. Organizational structures that have separated groups by each horizontal layer in their vertical story.
2. System architectures that are so complex and distributed, it takes months to get information from the right people and to coordinate an end to end testing effort.
3. Poor portfolio management where priorities are not aligned across groups and highly specialized skills are spread thin
4. When teams are unwilling or unable to change their mindset from big bang delivery to iterative delivery.
Example 1:
A financial services company has three separate business units that either support back office, middle office or front office. The teams working in middle office never interact or have knowledge of the customer. The business units only interact at the senior vice president and above levels.
Example 2:
The system architecture of a telecom company has not been able to automate their transactional processes. Many different functional groups try to automate and the data gets stuck in one of the many third party applications without ever synchronize to a single customer record. Manual processes must fill in the system gaps and the end user is not able to see the data. Synchronization would require coordination with all internal and external partners.
Example 3:
A program of teams is working in a vertically structured organization, non-legacy systems, and the solutions technology portfolio is complimentary. The only problem is leadership's inability to limit work in progress and spreading the talent too thin across initiatives. Too many projects in a program eventually will cause their own impediments. Teams get impeded, stories are put on hold and they start something new until an older story is unblocked. No stories ever get done in a given timebox.
Example 4:
A team practicing waterfall is forced to adopt agile iterative delivery but they can't seem to get over the incremental development mindset. They may not even have the skillset or information available to do anything but complete one of the layers. The idea of re-work is a negative outcome so they work from their own task list without ever really working from the user stories.
If you relate to reasons 1-3 and you are not a decision making stakeholder, simply get as vertical as you can possible get for your business and system context; otherwise, you have the power to directly impact time to market. If you fit into reason 4, identify what you think your constraints and limitations are and simply validate them as logical. Better yet, if your mindset is the problem, reach out to other previous non-believers and find some rationale to change that resonates with you.
