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.
If you have the skills but you just aren't seeing the success you deserve in your career, then do check out our Simple Programmer course “How to Market Yourself as a Software Developer”.