Horizontal vs vertical story slicing, or why is horizontal slicing considered as such a bad thing
Hi all,
This is my first post on the forum, so please treat me good! :)
I've googled for ages for this question but all answers and all blog posts/papers on the topic are so generic that they cannot be easily applied to my scenario. In the following post (which will probably be a bit longer one) I will first give a quick recap on myself and my team, how and why we do the horizontal slicing and my arguments why horizontal slicing of stories works well for us. I am quite young and having been working under scrum for three years, so the point of the post is to basically start a productive discussion with more experienced people who know far more than me :) I would also like to take this opportunity to personally thank in advance to anyone who chips in with their point of view!
Okay, so I'm a senior developer, team lead and basically a resident architect for a team of 5 developers. Four out of five of them are juniors, and for three of them this is their first job having joined the company 6 months ago. Info about the team is really important so I will give a quick recap with imaginary names:
- Developers A, B and C - Local developers, juniors, joined the company 6 months ago, on a project for 6 months
- Developer D - External developer located in Ukraine, junior, joined the company 3 months ago, on a project for 3 months
- Developer E - External developer located in Turkey, senior, joined the company a month ago, on a project for a month
I, myself, have been with the company for three years and for a year on a project and I have posses the most domain (business) knowledge out of all. What this basically means is that not only we lack business knowledge in the team, it is such a big challenge to work with, mentor and tutor all junior developers, alongside with working with external people from different time zones. The team is really young and ready to learn, but there is a looong road ahead of us before we really "get there".
Regarding the project, it is pretty stable:
- 2-week sprints
- Monthly releases
- Code freeze implemented and respected
- Backlog and sprint backlog maintained daily
- We use TFS, and we break down features into PBIs and PBIs into tasks
- All PBIs have effort assigned and we use Fibonacci series for efforts
- Usual scrum (sprint) ceremonies are implemented: daily standup, sprint planning, sprint review, sprint retrospective
Interesting about the project is that we rarely have small user stories. More often than not the client sends us over a documentation for a feature, which is a Word document of 30 pages on average. When estimated this more often then not becomes 200-500 development hours (not all team members work on all features because they are sometimes assigned to different initiatives, but for the sake of the argument consider it's 4-5 developers per feature). Now a disclaimer: this entire post applies to create PBIs for these sort of features. This post doesn't apply to single user stories as we do the vertical slicing for them. Please keep this in mind :)
The client doesn't accept "some" functionalities, an entire feature needs to be delivered to them within a single release. I will come back to this, but it is a really important point.
How we do the slicing of this documentation:
- We split the feature into user stories. No items are created yet, i.e. developers don't work on user stories.
- We then slice user stories horizontally
- For all horizontal slices, we create PBIs:
- Client side,
- Service side,
- Database (Note: more often than not "Database" part is included in Service side PBI)
- Every PBI has effort assigned and it is estimated. Tasks explain everything which needs to be done, e.g. for Service side:
- Create service operation
- Implement authentication and authorization
- Implement add order operation (this task is sometimes split on two for different architecture levels)
- Write unit tests
- Test
- Code review (assigned to me, most of the time)
For client side it's the same thing. Because 90% of the time the user stories (from first point in the list) are intertwined with the rest, this approach works really well for us. Especially because most of the time "client side" PBI is estimated for 30-40 hours, and service side PBIs are often between 25 and 35 hours. What this allows us as a team is:
- For developers:
- To work on independent user stories, and independent architecture levels
- To have a clear understanding of what they need to do on a task level (now comes the inexperience of the team - this is where horizontal slicing shines in my experience)
- To not have to know everything about the feature, but only the part they are working on
- To tackle one problem at a time
- For myself as a team lead and for our project managers and scrum masters:
- To monitor the progress closely on both user story level and architecture level (e.g. developer A finished service side for first component, developer B is wrapping up client side so we can expect it to be done shortly). This is done by not having to assign people tasks on multiple PBIs but to assign them PBIs to work on
- To have smaller and more granular items so they can be monitored a lot more easily, on both daily and on retroactive level (number of bugs on certain architecture part, who made them, when they made them etc).
- To have clear efforts applied and to monitor on which parts of our system we make the most issues
- To not have PBIs which take more than 4-5 days to finish (we aim for 3.5 days at most but of course sometimes it's not possible)
- To move people around different architecture levels so they can improve themselves
I think I have summed up most of the pro things for this approach. Some of the clear cons that came up in my experience are:
- Developers don't get to see through all of the user story life cycles, which would be a nice thing for them. But, after we're done with every feature we have a sprint or two where all PBIs are just single user stories and we do the vertical slicing there.
- There is a part where Client and Service side PBIs must be integrated. While inherently a tricky point (who should do it, is it a part of client or service side PBI etc. Vertical slicing doesn't have these issues), we do have an agreement that this is a part of a Client Side PBI. Might be wrong in theory, but it works well for us.
During my research time I've found plenty of arguments against horizontal scaling and I'd like to take a minute to comment couple of them:
- Client side and Service side PBIs are not deliverable, i.e. they don't provide any business value -> I completely agree. This is the biggest issue I have found with horizontal scaling but my response is pretty simple: user stories are not business value on our projects, features are business value. In our entire process for these big features, a single user story out of the feature is not delivered to client on it's own. In other words, we don't deliver user stories from features, we deliver features themselves (which are in turn consisted of multiple stories). Even if we did vertical slicing we wouldn't go to production with 20% of feature developed, we go with 100% or with none of them.
- This sort of PBIs raise a lot of questions for QA like which items should they test, how, etc -> Again, completely agree but the same comment from above applies here. While QAs cannot directly test "Client side" PBI, they test a feature. Same goes when our clients come in when we go to UAT - they test a feature, not a user story (because we deliver a feature).
Phew. If you made it this far - thank you! Just to sum up, I've mentioned three biggest issues and challenges we are facing as a team and if you didn't catch it here is how horizontal slicing of features solves them:
- Team's inexperience and immaturity - by having client side, service side (and sometimes Database) PBIs, we manage to clearly define tasks and provide a thorough description of what needs to be implemented. Team members concurrently work on multiple PBIs and since they're on different architecture level they don't go into each other ways.
- Team's lack of business knowledge - by focusing on technical things the team member assigned to the PBI doesn't have to know a lot of business rules. All new rules are clearly defined and explained as much as possible, as well as technical things the developer needs to implement, so the risk of breaking some other feature is extremely low.
- Feature is a deliverable, part of the feature is not - vertical slicing isn't something we must implement. We don't deliver user story, we deliver a set of user stories. What this means is that clients don't care whether we have client side and service side PBIs or user story-based PBIs as long as an entire feature is developed and delivered.
And that's it! As I mentioned in the beginning, I am a fairly young developer and there's plenty more to learn, so there is a big possibility we've been doing these things wrong. But, from my experience in the previous six months horizontal slicing has worked flawlessly for these developers.
Are we doing it wrong? Have you been in a similar situation, or do you work differently? I would really like to hear a different side of the story, i.e. how would vertical slicing work and solve the critical issues we have? If you do provide good enough arguments I would gladly try it out and see how it goes, but there's a lot on the line...
Or, you know, if you agree with me that horizontal slicing is not that bad... let me know! I sure do need some support with this :)
Thank you all and have a great day!
Are you sure that these “user stories” are independent? Do they deliver value independently? Or do you mean that they increase the chances of developers working independently of each other, with reduced incentive to collaborate?
Other things to consider:
- The importance of the INVEST criteria when framing user stories
- The significance of Card, Conversation, and Confirmation when implementing them
- The purpose of teamwork. What really makes a team a team, and not just a group?
Is there a desire to validate assumptions early, and change direction based on the results?
From some of the things you've said, it sounds like functionality is defined specifically and in advance of building. If there's no need to validate that any of this is correct, before it's all done, then maybe there is no need to slice vertically.
It could be quite expensive for your clients though, if they're making these 30 page Word documents, and paying for 500 hours of development on an assumption that turns out to be incorrect.
Here is why I think vertical would be better for you. Your client is expending a lot of work to define something that they want and are willing to pay for a lot of hours of development. However, 500 hours of development does not happen quickly. So how much can change in their world before you can deliver them something to see in a horizontal slicing method? I get that they won't accept anything but the whole product. But that does not mean you can't show them your progress and get their feedback? Vertical slices give you something to show them in increments and then they can adjust their needs based on what you show them. And sometimes you might even be able to "deliver" the work in less time because they could determine that the remaining scoped work is not really necessary. It will be cheaper for the client in the long run. You will build a level of trust with them that will keep them coming back to you to do the work over finding someone that will quote 400 hours for the same job.
The reason that Agile encourages vertical vs horizontal slicing is for the transparency of what you have done, the ability to inspect that work and then adapt to the reaction/feedback from the client.
One of the best analogies I've ever read comparing horizontal to vertical slicing is the construction of the Empire State Building.
Research how it was actually built (not according to the original plan!), and you may gain some valuable insights into the benefit of vertical slicing.
If we have a business requirement document then again do we need to first understand the architecture, then do vertical slicing? First create a product backlog and then Break the requirements into EPICs/Features and then user stories? Product backlog is not an exhaustive list. Do we need to bring all the requirements from business requirement document to product backlog?
@upasana chaudhary, The BRD could be a starting point to capture what is needed in the Product Backlog. Would you be able to develop and test an end-to-end functionality small enough to fit in a Sprint? Maybe that should guide you on what you should do next, perhaps?
I would like to present another case in this conversation. There is a system to generate reports based on client's request (internal reports). The client wants to four more fields in the report presented in a certain way. The reports are hosted on a UI platform, so there is UI changes involved. To add these four new fields the team needs to add four fields to a table where the information will be pulled from multiple different tables for this four columns.
so there is a database change
then business logic and then UI change. Client wants all these new fields together, presenting them one at a time does not add any value. Having one story for all these work, will make the story super big and complex. SO they decided to create three stories. One for database change and one for business logic and one for UI. QA confirmed all these stories can be individually tested.
What does community want to say on this?
Hi, I would like to post another case on this discussion. Would like the see what all of of you have to say.
@Naresh VK My opinion is that you can still do vertical slices.
First Slice: all fields added to DB, UI provides ability to view the fields. Show that to the customer, with data insterted via SQL, to ensure that the placement on the screen is satisfactory.
Second Slice: Give ability to enter data via UI. Now stakeholder can see how the flow would be for entering and viewing data.
Third Slice: Full ability to manipulate the data via the UI (Create, Read, Update, Delete). Full system delivered but you have 2 opportunities to gain user feedback prior to completion.
@Daniel Wilhite, thank you for the reply. May be I can provide more details on this.
Here is the scenarios
- This is for reporting purpose, the fields are related to look at some information. The placement of the fields in UI has been vetted by the clients through mock ups.
- There is nothing to enter from UI, so no update, delete capability. It's for view only. The new fields will get the data from bigger enterprise database.
- In terms for validation, clients does not want to validate anything on the approach, they need the fields for the reporting.
@Naresh VK Do the team think that they are able to tackle it in one sprint? If yes, where exactly is a problem here? At the end of the day, in the trenches where development occurs, the work always looks like horizontal slices. The question is what do you pursue - is it pursue finishing a phase i.e. "Setting up database"? or rather is it a working piece of functionality, that you pursue?
Consider what would happen if you slice the work in your example vertically, the first approach that comes to my mind is to slice it through fields of data to represent. So you will end with 4 slices that might be delivered independently to each other.
I know that you wrote:
(...) Client wants all these new fields together, presenting them one at a time does not add any value. (...)
But slicing it by field is not equal to not delivering them together at the end of the sprint. The benefits of that slicing would be also better risk management, more feedback, and collaboration (i.e with business) opportunities and increased chances to deliver at least some working increment if something surprises you along the way.
I also doubt that this statement of presenting them one at a time does not add any value was true. Ask the client: if he has to choose only two of them, which two would he want in the first place?
If he still hesitates to make a decision, give him a coin, split those fields into groups of two and ask him to flip that coin for the first group or do it one by one. 9 to 10 people know the answer to what they want in the moment of flipping a coin, just before it lands on the ground. Simple yet effective method.
@Piotr Górajek, I agree with you. I proposed the same approach of creating four stories for each of the field and presenting to the client for feedback. In the end, team mentioned setting up the database for these four fields together is much faster than requesting one at a time. Also client understands the database aspects as well, they just don't look into only UI. They are savvy in SQL and other technologies. Also having all these elements together in one story will make the story bigger and more time to develop and testing. So they decided to develop and test it piece by piece.
In the end, my point here is Vertical slicing is very good, not doubt in that. Also there are cases where it does not make any sense to stick to it. I see many agile practitioners push for vertical slicing rather than solving the problem of delivering the functionality to client. The ultimate goal is delivering value to the client. Writing user story is just a mean to achieve that goal.
@Piotr Górajek has good advice. He also two good questions.
Do the team think that they are able to tackle it in one sprint? If yes, where exactly is a problem here?
If they can do all 3 of the stories at the same time, just do it. But be wary of them deciding to do this on all stories as it can lead to the delaying of value delivery if they start to sequence the work.
The teams I work with find themselves in a similar situation to OP, I'm curious to get the communities thoughts on our experiences as it relates to vertical vs horizontal slices.
I should start by mentioning our experience with Scrum is affected by the fact that the product is very much in progress and what we consider a shippable MVP is a ways off until many Epics can come together to create a valuable release. This means that while we try to be transparent with external stakeholders about the direction of features, our primary stakeholders are internal and understand the situation.
When we tried vertical slices, we found that decomposing the PBIs was easy and felt good. But in practice, what happened is that one of the slices would always become the front runner for laying down key architectural pieces. that work in itself was not something that could be spread across vertical slices. This led to confusion in and out of the development teams ("which slice is taking care of this infrastructure piece again?" "why did this one PBI take so much longer than the others? It's just adding a button!"). The teams found there were integration problems even vertically. Compounding this were cases where even thinly sliced vertical pieces could not fit within our 1 week Sprints. It shook confidence in the teams.
We have since switched to horizontal which the teams find more comfortable and familiar but I am concerned that this will hurt us when MVP is reached and we switch to a mode where external stakeholder feedback becomes a much more readily available and important. It also is somewhat demoralizing to end a Sprint saying "yes we finished, but it was back end work only and we have nothing to show". That also seems to erode confidence.
We continue to inspect and adapt, if we find a good balance I'll happily share here.
Hi Mike,
(...) We have since switched to horizontal which the teams find more comfortable and familiar (...)
Doesn't that approach is truly easy in comparison to vertical slicing? I can imagine why it is a more comfortable feeling, and I also already have questions in my mind:
- How often we run into misunderstandings, re-work, and integration issues late in development (as it looks like something that spans across many sprints)?
- And how many of those issues could be found earlier if we rather challenge ourselves to finish working increments of solution each and every sprint?
Having potentially releasable increment at the end of the Sprint does not equal to being viable to release it to all of the end-users form a business perspective. If we really want to, we should be able to do it, even if it doesn't make sense. But maybe having that opportunity enables us to gather better feedback i.e. from early adopters? Or maybe these walking skeleton will change the perspective of those what you called them:
our primary stakeholders are internal and understand the situation.
and foster better collaboration and even a change of course? Often things that look promising on paper, or on designs/wireframes, at the end of the day when you can actually use it a little, are no longer so promising.