The Problem: Everything is a Vertical Slice!
Recently, the project that my team and I are on experienced a rough patch. In short, everyone under-delivered. I won't go into a lot of detail on this, but I would like you to keep in mind that this is a multi-team project, and when I say everyone failed to deliver I mean *everyone*, not just my team.There were a number of factors that contributed to the failure to deliver on the prescribed schedule, but one of the primary issues we identified was large user stories which had not been broken down into small, atomic chunks. Essentially, each story we worked on was a large vertical slice that would take several days to complete. Our estimation scale is 1, 2, 3, 5, where 1 is the smallest increment, 3 is a large story that might take about a week, and 5 was just way to big to accurately estimate. While we didn't allow 5's to exist, we were far too tolerant of 3's.
This caused our velocity to drop precipitously over the course of 2-3 months. It was difficult to show progress during an iteration as completing each story meant going through all the layers of code, from the front end, through the various service layers and finally to the database, as well as completing what would normally be a large code review (to be performed remotely by someone on the other half of our team). Furthermore, with four pairs of developers, each working on stories of this size, there was little in the way of incremental delivery.
Finally, after it became apparent that we were in trouble our project manager rightfully gave us a kick in our collective rears and told us we needed to course-correct as of yesterday.
Mitigation: Do Not Attempt to Adjust Your Picture. We Control The Horizontal. We Control the Vertical.
So course-correct we did. As a team we sat down and identified where we had gone wrong, and how to save the project. Among other things we decided to no longer tolerate large stories that might not be completed within a week, and to break stories up horizontally rather than vertically.Rather than work through all layers at once each story would focus on a single layer at a time. One story would cover the database, the next the service layer, the next the UI, and so on and so forth. 3's became the new 5, and stories were broken up such that smaller stories (1's, and 2's) became the norm. If a 3 were encountered it was immediately suspect and considered for further break-down.
These changes worked wonders on our velocity. We began completing stories more quickly, and story points began to quickly accumulate earlier in the sprint. The team's attitude began to brighten as well when we saw the results of our changes. This was no longer an impossible death march; it was a death march we could complete and turn into a positive for everyone involved.
Advantages of the Horizontal Slice: Harder, Faster, Better, Stronger
Smaller Story Size - As I said earlier, one of the advantages of breaking stories down in this was was smaller story size in general. We no longer had to worry about working through all the layers in single story. As long as a stable, agreed-upon interface existed developers could code to this interface, mocking out dependencies appropriately and depending on the unit tests to insure that everything worked as expected. In short we were using interfaces the way they were meant to be used.
Parallel Work - Another major advantage was the ability to complete a vertical slice in parallel. This vertical slice could now be done in just a couple of days on average, as opposed to the serialized work we were doing previously. This proved to be of huge importance in the face of the new pressure, as it allowed the team to quickly work through features and keep up with the increased demand to get ahead of the delivery curve.
Delivering Value Early - Now that the stories were broken down into pieces that could be completed in just a day or two we could show value much sooner, and more often during the sprint.
More Accurate Estimation - This is a side-effect of the smaller stories. Now that we were breaking things down into more granular pieces it was easier to come up with an accurate estimate of the complexity for any given feature.
Disadvantages of the Horizontal Slice: You're Gonna Carry That Weight
Higher Overhead - One of the side-effects of our new strategy was in increase in the overhead of pushing stories faster. The first pain we encountered was being blocked by the code review process, which is required before anything can be considered "done". Because we were pushing code more frequently we found ourselves waiting for the remote reviewer to complete their work more often. Obviously we were exposing a pain point in the existing process, and while this was a better problem to have than not pushing enough code fast enough it was still a point of contention.Fewer Integration Tests - This should be no surprise to anyone familiar with working horizontally rather than vertically. Without having the underlying layers in place writing integration tests became much more difficult, and were completed after the fact (obviously not ideal for a team that prides itself on TDD'd software). I still go back and forth on this, as I want to have the integration tests in place at the beginning of the process, but still be able to push test-driven code frequently for the layer we're currently in.
More Technical, Less User-Driven Stories - While the overall value stories were still in place, the stories themselves became much more technical in nature. This becomes a problem when the product owner should be signing off on whether or not the work is accepted, as they almost never know the technical requirements of working with the database, the services, etc. Our product owner is not interested in these things (nor should he be!), and for these stories he doesn't have direct visibility into the system until all the pieces are put together, allowing him to get his hands on the final product.
Conclusion: You Gotta Give A Little To Get A Little
Our mitigation strategy was ultimately successful as it allowed us to deliver all functionality on time, and to show progress much earlier in a given sprint. Our velocity increased significantly as we worked through more stories, and we were able to have multiple pairs working on the same feature.
While I'm generally a big advocate of working on vertical slices, I'm beginning to form the opinion that "value" should be delivered vertically, while user stories work just fine in horizontal slices. Yes, there is still some question as to how stories are accepted by the product owner if they don't understand the underlying codebase, and that is a point we are still working through. This was a successful strategy for this given team in this given scenario, but it is entirely possible that another approach might've been equally successful.
I hope this post has been insightful, and I would love to hear feedback and ideas on how you, the reader, might've approached the situation differently. Thank you.
