User Story as Vertical Slice

When working with user stories, the phrase “vertical slice” comes up a lot, but a lot of Product Owners and especially developers have trouble understanding what it means and how to tackle it. And even if they understand the concept, the execution may end up being problematic. Here are some suggestions that I hope will help move your team forward on this path.

What is a User Story?

First, let’s talk about a user story. They aren’t a requirement of Scrum – they’re a concept borrowed from eXtreme Programming (or XP) – but they’re an ubiquitous instantiation of a product backlog item. A user story describes a system behavior from the perspective of the user of that system. Usually written in the form

As a <role>, I want <functionality|behavior|feature> so that <value>

Roles can be defined formally (using personas – a future post) or informally. Provided that everyone understands what the role is and who it represents, the team can usually work through it.

Functionality, behavior, or feature sections are pretty self-explanatory. This would be some kind of behavior in the system (or feature), but from the user’s perspective. It wouldn’t generally be something like “a normalized relational database” or anything – users don’t care about that. What they want is to accomplish something or complete a task. This is where that “what I want to do” will be captured. It’s important that the what is captured, not the how. An example might be “I want to print my document”.

The value portion of the story describes why the team is being asked to do this. It helps the Product Owner explain why something has been requested and what kind of value the story has as compared to others. Value statements can be a little difficult to write, but it should state what the business or user value is. An example of a value statement might be “so that I can view my documents when I’m not at my computer”.

What’s a Vertical Slice?

Now that we have an idea of user stories we can start talking about vertical slices. Sometimes, when working on a project, there are multiple layers of architecture that are implemented. Talking through the traditional “cake” analogy we use in agile, the idea is that our whole product is a multilayered cake. What this might entail is something similar to the image to the below. The cake would constitute all of the work and each layer would represent all of the work for that part of the product. Note that in this analogy we’re not talking about how we make the cake, but rather how we’d consume/eat the cake (yummy!).

In this example, there are three main layers in the application: the user interface, a middle tier, and a back-end database. Commonly (and traditionally), each part would be worked on separately by different teams (or at least individuals), likely at different times. Because each team is working separately but on the same project, the teams will need to talk to each other and coordinate deliverables, requiring “hand-offs” and “integration touch-points” to make sure that each team did what they needed before transferring the work to the next team.

It’s recommended from an agile perspective that teams work on stories that consist of vertical pieces of the cake; in other words, slices. People don’t eat layers of a cake. We don’t eat all the top layer before we start eating the second layer – we cut the cake into slices (thin or thick, depending on your preference and diet) and then eat those. Again, looking at the cake as the whole product, a vertical slice of cake means a user story should contain work for as many of the different layers as possible.

Feature Teams and Component Teams

Of course this means that we have a bit of a struggle because nine times out of ten, our teams are aligned based on function or layer rather than product. We have independent teams consisting of user interface folks, database folks, middle tier folks, etc. In agile we ask that we have what are called feature teams rather than component teams. Feature teams are cross-functional – they consist of all of the talent necessary to actually do the work required for the product. This way the team is aligned with the product and are responsible for the success of the product as a team. Component teams deliver a part (component) of the whole system. Database modeling, gap analysis, user interfaces, etc. are all examples of components.

There are times when component teams are needed, but those should definitely be the exception and not the rule. Component teams, by definition, work on only a part of the whole. When they complete their work, there’s still work to do; there’s still value that’s not yet delivered. And many component teams need to hand-off work to other teams, meaning delays and possibilities for miscommunication or misunderstandings. The fewer of those we can have, the better.

Starting with Vertical Slices

Product Owners should work to start big with features and then break those features into work items the team can complete quickly. Look at the product from the customer’s perspective – it is a user story, after all. What should the product do from their viewpoint? What does it need to do and what would be nice for it to do. Now you’re starting to look at backlog prioritization. But let the team bring the how – what needs to be done technically – to implement the story. The best way is to just start writing. Keep to the template above and you’re halfway there. Keep it focused on the customer’s needs and avoid explaining how to do it. Congrats! You’re well on your way!

A quick warning. Your teams may be inclined (due to experience, training, etc.) to try to break stories into layers – DB, UI, etc. Do NOT let them do that unless there’s a very good reason. Talk with an Agile Coach if you have questions about how best to proceed.

Good luck and happy story writing!