Choosing Between Horizontal and Vertical Story Splitting

Imagine arriving at an intersection with multiple road directions all leading towards the same destination. Some roads may take faster to drive, others — less traffic lights to pass through. But which way do you go? And how do you make up your mind which one is the best, given different circumstances?

Such is the case for user stories too. On one hand, their basic structure follows a straightforward format, regardless of the work items included:

 

As a [role], I want to [action], so that I [business value].

 

On the other hand, tending to any external demand for a user story entails making a much more thought-out decision. It necessitates a series of conversations about the various levels of detail and functionality. Stories are first and foremost meant to serve as a tool to enhance teamwork. Equally as important though, is to further show the value of the team’s work to the project’s stakeholders and all potential or existing users. This is where the verbal coordination needs major adjusting. Since the level of technical understanding on both sides is vastly different, software service teams need to bridge the gap by mustering the right approach to take users on board with their development.

Teams, stakeholders, and end users often come into contrasting opinions due to their own distinct levels of technical understanding.

 

Understanding Story Splitting

Building user story layers is the mantra in the work of any well-organized development team. But it’s one thing to stack a solution with layers of functionalities and another conveying the engineered progress to the client. To tick all checkboxes when immersing users into a user story, let’s adopt the following cake analogy.

Just like developing and stacking layers, it would take much less time to slice a cake horizontally. While still edible and somewhat tasty, the cake servings will be uneven and dull in taste and will probably drive most ordinary consumers away — those craving for the full spectrum of flavours. Naturally, that’s what stakeholders want too — a symbiosis of all tastes and layers. In other words, they want a piece of the entire product. A wholesome introduction to all features and layers works differently — and oftentimes better, than the individual examination of singular components.

 

Horizontal Slicing

To illustrate this approach, let’s take a step back and imagine a product owner coming with a request to build an ATM. To assemble it would require a debit or a credit card and a type of a UI that will enable them to select a sum and prompt them to use a PIN to then receive money.

Expectedly, the requested software would carry a considerable amount of layers — a database, an API, security and network layers, and a functional UI. Given that they all need to comply with either banking or ATM protocols and procedures, it becomes difficult to encapsulate all elements needed for a simple, small portion of a feature that’s being described and documented. Therefore, teams are incentivized to split requirements into layers based on the scale of engineering, rather than by end-user or stakeholder value.

 

Disadvantages

Minimal transparency — Involving people external to the team’s daily project advances is never an effortless process. After all, it’s clients who are the prime decision-makers and as such they yearn to maintain a level of close communication with the engineering team — a practice that continuously takes longer and harder to coordinate.
Obscure priorities — Mismatched priorities are a team’s worst enemy. Prioritization is always key, but when it’s done improperly, it could passively increases delivery risk.
Logical lapses — The work of developers often pushes towards the next logical component in the system that needs to be built, rather than what the end user needs most often. This could be observed with ATMs too. While withdrawing money accounts for about 90% of any ATM’s usage, other features like checking the balance or changing the PIN are also there for the sake of user convenience. Developing them could easily be moved post-MVP.

 

Vertical Slicing

Unlike horizontal splitting, this model considers the purpose and goals of the average product owner. A PO is usually someone constrained by a budget limit, driven to achieve a specific goal within a specific timebox while showing constant progress to other stakeholders. Their interest is to observe something visual, which, in turn, would justify the spent budget. Just like them, users will think of an application in terms of the behavior they find most valuable.
This explains why it’s simply impractical to build software the same way users think about and use that software. Instead they need to receive ‘slices’ of functionality, or splitting user stories into vertical chunks. While the size of any story can vary, the best practice is to shape them so that they fall under shorter timeframes to complete — usually within a day or two.

It also allows the engineering team to prioritize its focus on a set of stories within a specific portion of the system. This process isn’t intrinsically easy, but it is well worth the effort because it gives the ability to create a constant flow of valuable, usable functionality for the users.

Nevertheless some stories cannot be split, due to either:

• Ambiguous requirements
• Uncertainty in the depth of the implemented technical details
• Enormity of some items which are too big to be logically split

 

Advantages

The crucial and often underestimated value of splitting stories vertically is the boost in communicating with the development team. The multiple merits — continuous conversation, improved engineering process, and tending to the business value — help set the tone for understanding the scope and complexity of any project.

Other conveniences of vertical splitting include:

• Asking the team to proactively participate and engage, which:
  • Improves the synergy between members
  • Improves the quality of the product
  • Improves the building speed, thus making everyone more efficient
• Delivering specific features that stakeholders could ‘see and touch’ more frequently
• Enhancing the client-team relationship
• Setting reasonable expectations for all parties involved
• Eradicating project ambiguity
• Allowing for better estimates 
• Diminishing requirement-related risks 
• Allowing the PO to prioritize highly valuable items without any overhead
• Increasing steady delivery of features, which then increases the feedback coming from real users

 

The Main Challenge

Essentially, software products resemble more of an iceberg than a cake. That’s because, until the release date, the larger part of the software usually remains ‘hidden’ from the stakeholders. Here’s why it’s so integral for teams to find the most practical, easy-to-use way to adopt the vertical splitting inside the project.

Applicable in the case of building the ATM too, this strategy would allow for a simple withdrawal of money, implying that the security protocols are met. It would further register proper money deduction from a person’s account and instantly confirm the new bank account value.

 

Summary

With no ready-made template for adopting either horizontal or vertical splitting into any project, it’s in the engineers’ hands to weigh on the better match. In either case, keeping track of work progress on a constant basis and breaking down technical tasks into sub-tasks appears the most sound approach for tying product owners to the team’s daily progress.

Creating software with slices of value is never easy. But as part of the principles of Agile development, it provides the network for creating a constant flow of valuable, usable functionality for users, while striving for maximum simplicity and streamlined team objectives.