Disadvantages of vertical user stories

Question

The agile approach is to structure the work into vertical user stories and deliver a focused but fully functioning piece of the application from end-to-end. Because this is the new approach to building software I read a lot of literature about why this is better than horizontal stories but I do not find much about the disadvantages to this approach.

I already drank the agile cool-aid and I too agree that vertically slicing the cake has much advantages over horizontal slicing. Here is a short list of disadvantages that I could come up with:

• A developer might initially be slower at implementing a feature because s/he must understand all the technologies required to develop the story (UI + service layer + data access + networking, etc...)
• Overall architecture design (crating the backbone of the application) does not really fit this mantra (however some might argue that it is part of a user story to develop/change the overall architecture)

What are some more drawbacks of vertically slicing user stories?

Note: The reason I am asking this question now is because I am going to attempt to convince a team to start writing stories the 'vertical way' and I want to be able to bring up the possible trade-offs ahead of time so they won't consider the approach a failure when they are faced with the drawbacks.

Answer 1

I've been thinking about this exact question a lot.

I think it's important to distinguish between slicing by individual responsibilities vs. slicing by team responsibilities. I'll focus this answer mainly on slicing teams.

For some background: I have worked in projects with full-stack developers, single-tier developers, vertical (full-stack) teams, horizontal (single-tier) teams, and diagonal teams. By diagonal team I mean containing all the tiers needed for a story but not necessarily all the tiers in the system, and also possibly containing multiple developers focusing on the same tier(s); in other words vertical in spirit but maybe somewhat horizontal in appearance or in implementation detail.

Recently I have worked in a group that transitioned from horizontal teams to diagonal (nearly vertical) teams. It has been particularly instructional to see the same group of people aligned two different ways. It makes some advantages and disadvantages quite clear.

I'll round up my opinion so far with the following summary comparison:

Horizontal Teams

Advantages:

• Fosters good separation of concerns and loosely coupled tiers
• Much easier workload distribution management
• Easy for specialist technical lead to manage
• Fosters intra-tier collaboration, best practices, pride, and a culture of excellence
• Aligns with natural/emergent communication patterns

Disadvantages:

• Can lead to isolation of tiers and thus hinder inter-tier communication
• Enables tier "bubble" culture if unmitigated
• Difficult to take advantage of generalist leadership
• Hinders generalists

Vertical/Diagonal Teams

Advantages:

• All the parts of a user story in one team ("one stop shop")
• Specifically assists delivering n-tier stories in a single sprint (although do you really need that?)
• Fosters inter-tier collaboration and growth of generalist skills
• Supports generalists

Disadvantages:

• Much more difficult workload distribution management
• Enables poor separation of concerns and tightly coupled tiers
• Hinders specialization by curtailing intra-tier communication; it is difficult to see how a culture of excellence could arise out of this structure without adding mitigating horizontal/specialist behaviors

I do not think team membership has a one-size-fits-all solution. It seems pretty straightforward, however, that the vertical team lines up better for organizations requiring generalization. If your engineers are generalists and like working full stack, that's a pretty good reason to consider vertical teams. The horizontal team lines up better for organizations requiring specialists. If your engineers are specialists, that's a pretty good reason to consider horizontal teams.

As others have mentioned, secondary structures/behaviors that slice the other direction can help mitigate the drawbacks of either system. One interesting mitigating factor is sprint duration. Short sprints render some of the disadvantages of horizontal teams more tolerable. If you can build the backend this week and the frontend next week, that might be fast enough?

To apply some of these proposed principles to a real-world problem... I will say that the horizontal slices have worked quite well for a very real SaaS development team I've worked on that was solving very challenging technical problems in every tier (where specialization was in my opinion incredibly important), where frequency of delivery (and reliability at a high granularity/frequency) was critical to business success. Please note that this conclusion is for a very particular real-world team, not a general statement of superiority of horizontal slicing.

One caveat: I am probably biased against believing claims of generalist abilities by any individual in the modern software development world without significant proof, although I have known a few rare exceptional generalists. I feel that generality is a tall (vertical?) order indeed, particularly as each tier grows in complexity and with the proliferation of alternative languages/platforms/frameworks/deployments, each meeting different needs. These days especially, a jack of all trades can quite easily be a master of none. Also, anecdotally, I find most individuals want to specialize quite a bit, again with some exceptions.

Answer 2

I don't know of any long term disadvantages. In the short term, and for a team new to this kind of development, the main disadvantage is that it takes some getting used to and some learning.

The most efficient way to work vertically is to have full-stack developers: in this way a story can be typically executed by one person (or more than one but without pipelining tasks). Clearly this requires that the developers work vertically across the stack (from html to database in the case of a web application).

If your team is not used to working on vertical stories, then they are very likely to be doing the opposite: each person will have knowledge of one layer/tier of the application only. When you introduce vertical stories, you can expect the team to split them into tasks corresponding to layers and then distributing the tasks to different people. This will be very inefficient.

The best approach I can give regarding this is to tolerate this pipelining initially while making it clear that the long term goal is completely different. Have team members across layers pair program so to build up trust and eventually enable people to be completely independent.

I don't agree with the other answer that this approach brings technical debt. It can, but so can any other approach.

Answer 3

The big drawback I have found is that it makes it hard for a team to build the application following a unified architectural approach.

In the early stages of the project everyone will write their layers in isolation. The stories (and layers involved) will work, but when looking back at the delivered product at the sprint-end it'll be easy to see the slight differences between each developer's architectural ideas.

This kind of thing is inevitable, but not a blocker. I've tried to battle this in two ways:

1. Have lengthy design discussions with the team before implementing each story
   • This gets tiring quickly. It's often too early for anyone to make an informed decision and then you just end up arguing over stuff that will definitely have to change anyway.
2. Go ahead and develop in relative isolation, keeping in mind that you're building up technical debt.
   • The key here is to log the technical (architectural) debt as an issue. This is something that will need to be paid back.
   • After a few sprints it'll be easier to decide on a coherent and unified architecture. This is when you should request a hardening sprint to pay back some of your technical debt (refactor the existing code). Alternatively, you can pay it back piecemeal over the next iterations of the project.

The only other problem I can think of other than that is that there's usually a lot of boilerplate code to add at the beginning of a project. Writing vertical slice stories means the team's velocity on the first few stories will be artificially low due to this prerequisite boilerplate... but as long as everyone is aware that this should only affect the first couple of sprints then everything is fine.

Answer 4

I don't know any disadvantages either, however vertical stories can be implemented badly.

When I first started my career I joined a team that was keen to do XP but they had no experience with it. We made a number of mistakes when using vertical user stories.

One of the problems we encountered when doing horizontal work was that features did not integrate well across the layers. APIs often did not match the specification, features where missing and numerous other problems. Often because the developer of the had moved on to something else, you would either have to wait for them or do it yourself yourself.

Switching to doing Vertical Stories solved these problems and reduced/eliminated the waste of re-working to integrate.

There are a number of XP practices that support this way of working. Anyone needs to be able to work on any area and everyone is expected to fix the bugs they find (Collective Code ownership).

When you are making the change to vertical stories, it can be tricky to work in areas that you're not familiar with. Pair Programming can help, if you aren't confident grab someone in the team who is pair with them. I've found pair programming to be the fastest way to get up to speed with a new code base.

Without strong owners over layers we found, that there was some duplication emerging. Although this was not a big problem, we needed to make sure that we practiced Refactor Mercilessly (with appropriate tests to support).

Although I mention a number of problems, I don't think Vertical User Stories was the cause. In fact, it made the problems more apparent. After we made the switch, problems were no longer obfuscated across teams or application layers.