Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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. –  Dave Hillier Feb 7 '14 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 Feb 7 '14 at 21:39
Are you trying to say that the business perceive it as slower? –  Dave Hillier Feb 7 '14 at 21:59
Is a "vertical slice" essentially the same thing as a "cross-cutting concern?" –  Robert Harvey Feb 7 '14 at 22:12
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/… –  Robert Harvey Feb 7 '14 at 22:14

3 Answers 3

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.

share|improve this answer
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 Feb 11 '14 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.

share|improve this answer
How does it follow that from working independently you build up technical debt? Doesn't seem to be necessarily the case –  Sklivvz Feb 7 '14 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 Feb 7 '14 at 16:37
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 –  Dave Hillier Feb 7 '14 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 Feb 9 '14 at 18:59
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 Feb 9 '14 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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