Slices (Verticals), User Stories and Scrum

We try to divvy our stories in a way that they span from top to bottom; through all layers of the architecture. We call such an isolated part of a function or project, a “Slice”. It is also commonly known as “Vertical”.

But why develop in slices, or verticals, why even care about it, why not just do the User Story regardless and forget about if it is a horizontal or vertical or whatever…? Well, we’ve tried various approaches here. The one thing I am certain of is that this is hard. It requires skill to be able to produce “good” user stories. And not only is it hard, it is also very important: because badly formed User Stories can wreck velocity. Properly shaped and formulated User Stories is one of the basics, a requirement, for a well-functioning sprint execution. So, Hard + Important means that we have to focus on learning it and really spend time thinking about it – and continuously evaluate our approach and view of the matter.

Ok, so then why vertical and not horizontal?
If you do things horizontally, isolated to each architectural layer, then it will be hard for you to actually deliver working, testable code. By doing Slices you are forced to deal with every layer right from day 1. This foundation will then be built further upon, as you iterate the software with every new slice. Also, working vertically – meaning involving every layer in every slice – will often require different competencies (for example UI/web, C++ and SQL/db). Suits nicely with our cross-functional Scrum teams, doesn’t it?

To use Lean terms, it’s about decreasing the “batch size” and ultimately minimizing cycle time; i.e. the time it takes until you deliver something valuable to the customer. If you work horizontally it will take longer until the customer has something that brings value. A complete user interface, but empty of all functionality, is rarely valuable to the customer (and rarely “complete” for that matter, until you’ve built the underlying stuff). And it is definitely not something “releasable”. Remember that you want to strive towards having something releasable every sprint. Sometimes (often?) it doesn’t make sense to release “half a feature” (e.g. “Add User” without “Edit User” functions), but at least you need provide that option and let the customer decide what he wants and doesn’t want: don’t make the decision for him by implementing horizontally.

So what forces are in play here, with regard to stories, architecture and Scrum? Well, let’s recap;

• We’ve just concluded that we have a requirement to build vertical increments of the system: Slices.
• We also have a requirement to “finish” (Done-Done) things, with each sprint.
• We even have a requirement to be able to “Release” at the end of every sprint.
• And we have a requirement to think iteratively, i.e. we should come back continuously and refactor our code (continuous refactoring – see blog post below)