Posted by: jsonmez | November 21, 2011

Understanding the Vertical Slice

One of the biggest challenges in breaking down backlogs is knowing how to split up the work from a backlog into right sized pieces.

I’ve already talked about the concept that smaller is better, but I we haven’t really addressed the decision of how to actually divide a backlog up to make it smaller.


The default path

Most developers trying to break down a backlog into smaller chunks will automatically head down the path of using a “horizontal slice.”


This is how we tend to think.

What do I mean by a horizontal slice?

A horizontal slice is basically a slice through the feature or backlog that horizontally divides up the architecture.

Most things are built this way.

If you were to build a house, you would probably start by slicing up the project horizontally.

You would first pour the foundation.  Then put up the walls.  Then put on the roof and many more steps, leaving the finishing work for last.

This same thinking usually gets applied to breaking up backlogs in Agile development.

It would seem pretty silly to build a house where you finished one room completely at a time.

Agile software development is different

There is a distinct difference though, between developing software in an Agile way and building a house.

The big difference is that in Agile software development, true Agile development, you don’t know exactly what you are going to build until you are done building it.

With a house this is rarely the case.

With a house, you have some blueprints that you have drawn up ahead of time.  You know exactly where each wall will be and where each outlet will be.  You may have even built houses before that are very similar.

When building software, unless you are taking a waterfall approach and planning everything upfront, you don’t know what you are really building until you are done.

Before you object to this statement, consider this:

This is the point of Agile development.

Agile means responding to change.

Building a house, you do not expect the customer to say:

“Hmm, yeah, I don’t really like that wall there.”

“Actually, I am thinking we are going to need 5 bedrooms now.”

In software development, you are expecting statements analogous to the above!

So what is vertical slicing?

Simply put, building one room at a time.

But it’s not functional!  Who wants a house one room at a time?!?

Correct! It is not functional as a house, but we can pour more foundation, change how we are going to do the rest of the rooms and even knock down the walls and start over without incurring a huge cost.

The point in building our software “one room at a time,” is that we are giving the customer a chance to see the product as it is being built in a way that matters to them and enables them to test it out.

Sure they aren’t going to be able to live in it until it is all done.  But, they will have the ability to step into a room and envision it with all their furniture in there.

Customers don’t care about foundations and framed in walls.  As a developer, you might be able to look at some foundation and framed in walls and envision what the house will look like, but the customer can’t and worse yet, it can’t be tested.

Vertical slicing in software development is taking a backlog that might have some database component, some business logic and a user interface and breaking it down into small stepwise progressions where each step cuts through every slice.

The idea is that instead of breaking a backlog up into the following:

  • Implement the database layer for A, B and C
  • Implement the business logic layer for A, B and C
  • Implement the user interface for A, B and C

The backlog is broken up into something like:

  • Implement A from end to end
  • Implement B from end to end
  • Implement C from end to end

Sounds easy enough, why the debate?

Because it is NOT easy.

I’m not going to lie to you.  It is MUCH easier to slice up a backlog horizontally.

As developers we tend to think about the horizontal slicing when we plan out the implementation of a backlog.

We tend to want to implement things by building one layer at a time.

Thinking about how to break apart a backlog into vertical slices requires us to step outside the understanding of the code and implementation and instead think about the backlog in small pieces of working functionality.

There is almost always some progression of functionality that can be found for a large backlog.

What I mean by this is that there are almost always smaller steps or evolutions in functionality that can be created in order to produce and end result in software development.

Sometimes the steps that are required to break up a backlog vertically are going to result in a bit of waste.

Sometimes you are going to purposely create a basic user interface that you know you are going to redo parts of as you implement more vertical slices.

This is OK!

It is better to plan small amounts of rework than to build up an entire feature one horizontal slice at a time and have to rework huge parts of the feature that weren’t planned for.

So what is the benefit?

You might be thinking to yourself that this sounds like more work without much benefit.  So why would I bother to break up a backlog vertically?

Is it really that important?

I’ve already hinted at some of the benefits of slicing things vertically.

The true impetus behind vertical slicing is the very cornerstone of Agile methodology.  It is about delivering working functionality as soon as possible.

We aren’t going to cover the whole reasoning behind this idea in Agile development.  I am assuming that you already subscribe to the idea that delivering working functionality as soon as possible is important and valuable.

Based on that premise alone, you can see that horizontal slicing is in direct violation to one of Agile methodology’s core tenants.

It is interesting to me how many people are huge proponents of breaking entire systems up into functional pieces that are delivered one piece at a time, but are so opposed to doing it at the micro scale when dealing with individual backlog items.

If you are opposed to what I am saying about vertical slicing, you really have to ask yourself whether or not you truly subscribe to the same idea applied at the larger level, because there really isn’t a difference.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code.  Also, you can follow me on twitter here



  1. […] Understanding the Vertical Slice (John Sonmez) […]

  2. I think this approach is very similar to a band jam session. Just playing along and find some nice chord progressions or drum patterns and so on. But there is a component which never comes up in software development theories and discussions. And this is the actual skills and ability of the developers involved. It seems to me that all these approaches are very good but only if the team using it has skilled enough members to actually think only in terms of functionality. How can this be applied effectively in a team that has problems at implementing the actual code? Which happens often in outsourcing companies that take whatever project that they can find regardless the technology or tools that are implied to use.

    • That problem cannot be solved. Using your example, there is no coaching that can help a band composed of players who cannot play their instruments. Band members have to practice on their own to be able to contribute to the band.

  3. That is super information! Thanks for sharing! I’m going to Tweet about your blog.

  4. […] Articulo traducido al español desde […]

  5. Great post. In my experience, the hardest part of getting this sort of “vertical development” working is changing the development team’s mindset for this. Rather than thinking “wouldn’t it be cool to add this feature to the framework”, thinking “do I need this feature in the framework to complete the feature I’m working on”? Ultimately it also needs the developer have a good understanding of what SOLID is and how to implement those principles – without that, it’s very difficult for a developer to implement vertical slices in a cost effective manner.

  6. Thanks for the post, you have a great site! Tobias Mayer said so in his post and had to come and have a look. Right he was!

    • Your welcome, thanks for checking it out.

  7. I agree totally. To extend your analogy, think about a (housing) developer setting up a new development. He won’t lay the foundations for all the houses before building the walls.

    He’ll create one or two, completed as ‘show houses’ (a vertical slice) where the potential customers can see an example of a finished product. They may ask for their house to be different (more bedrooms). Vertical slices allow the whole housing development to be developed ‘Agilely’.

    Cheers, Paul

  8. […] je User Stories zodat iedere story iets van waarde voor een user oplevert. Elke user story zou een vertical slice uit het product moeten zijn, dus èn een beetje user interface èn wat middleware code èn wat […]

  9. What actions can we take as developers to ensure the delivery of vertical slices can still give us highly maintainable and extensible solutions??

    I work in a company as a business solutions developer where our applications tend to live for decades, so getting it right the first time is very important. If we move to using vertical slicing how can we make sure we don’t deliver half-baked solutions that the business deems “good enough” and we are left supporting it for years to come.

    It’s easy to see the benefit for shrink wrap solutions where speed to market is the difference between being the innovator or the imitator. I’m just looking for a good way to make this apply to our software life cycle. Thanks.

    • Great question.
      Two things I would say about that:

      1. You don’t have to release until you are ready, but it is still beneficial to develop in vertical slices.
      2. Get feedback as you are developing from the customer and they are likely to keep giving it. In some ways you are also the customer, so, supporting it is a feature and it is required.

      Basically what I am saying is, vertical slicing is a way to develop an application solution better and get feedback faster. You still control the cadence of releases and determine what is done. Don’t be afraid to wait until the solution is not half-baked or to make sure you add future maintenance as a feature.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: