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.

  • I don't understand how the two points you list are disadvantages. You say might be slow, but they equally might not. What do you mean by overall architecture does not fit? Again it might fit better. Commented Feb 7, 2014 at 20:56
  • @DaveHillier: It is phrased in such a way where it is a disadvantage. For example, the business might think that 'slow' implementation time is a disadvantage.
    – c_maker
    Commented Feb 7, 2014 at 21:39
  • Are you trying to say that the business perceive it as slower? Commented Feb 7, 2014 at 21:59
  • Is a "vertical slice" essentially the same thing as a "cross-cutting concern?" Commented Feb 7, 2014 at 22:12
  • 1
    There's a very good article about Horizontal and Vertical User Stories that goes into great detail about the advantages and disadvantages of each, here: deltamatrix.com/… Commented Feb 7, 2014 at 22:14

4 Answers 4


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


  • 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


  • 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


  • 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


  • 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.

  • Your analysis here is great, and fits what I've experienced. I slightly disagree that horizontal teams can "hinder communication of inter-tier dependencies": I'd say that the horizontal separation makes the need for a clear contract between tiers clear and obvious. You do note on the opposite side that vertical teams can lead to tightly-coupled tiers. Finally, I agree that the claims of generalist abilities are almost always exaggerated (having seen many truly dreadful back-end designs made by "generalists" who really should stick to front-end).
    – SebTHU
    Commented Apr 25, 2016 at 14:19
  • Good point, @SebTHU. The wording of my first bullet on disadvantages of Horizontal Teams on "hinder communication..." was unclear. I intended to point out that Horizontal Teams can potentially lead to isolation between tiers and thus hinder inter-tier communication. However to your point, it can shine a bright light on the need for clear contracts and indeed be a forcing function to get contracts properly specified. I've updated that part of my answer to clarify my intention.
    – Will
    Commented Jul 13, 2016 at 21:17
  • @Will "Much more difficult workload distribution management" based on what? One guy pulling a single story and wiring up all the pieces seems really straightforward and efficient to me. "Enables poor separation of concerns and tightly coupled tiers" who says this is more likely in a vertical team vs a hoz one? If your team is disciplined (which I'd argue is required of both types of teams) then this shouldn't be a problem.
    – cottsak
    Commented Aug 1, 2016 at 3:53

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.

  • I would try pair programming. This will enable people to get the knowledge on the other domains they need and helps to avoid pipelining.
    – user99561
    Commented Feb 11, 2014 at 13:00

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.

  • 2
    How does it follow that from working independently you build up technical debt? Doesn't seem to be necessarily the case
    – Sklivvz
    Commented Feb 7, 2014 at 16:01
  • It's not necessarily the case, but it does increase its probability. Take code duplication for example. If some of the technical domain terms aren't solidified yet two devs might write the same functionality in two separate classes. The only difference is that one dev called it a WobbleAdapter and the other a WibbleConverter.
    – MetaFight
    Commented Feb 7, 2014 at 16:37
  • 3
    You don't explain why these problems are more likely to occur when dividing work in layers or vertically. And why would you have to write lots of boilerplate in the first iterations? Sounds like YAGNI Commented Feb 7, 2014 at 22:06
  • Sorry, I guess boilerplate is the wrong term. All I mean is that since much of the project infrastructure classes will need to be created in the first few sprints there is an one-off overhead involved.
    – MetaFight
    Commented Feb 9, 2014 at 18:59
  • 1
    And dividing work in vertical slices means each story touches a greater number of layers. This increases the chance of two developers coding parts of the same layer in relative isolation. Which can lead in mismatched implementation approaches. ... this feels very abstract... I'm willing to agree what I'm suggesting could be relatively unlikely!
    – MetaFight
    Commented Feb 9, 2014 at 19:03

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.