Spoiler alert – if you’ve come here looking for the definitive answer on vertical vs horizontal splitting of user stories I’m going to disappoint you. The old joke about consultancy rings true here…:
Q: How do you get a straight answer out of someone with a professional interest in UX?
A: “It depends…”
The fact of the matter is that how I split my stories really does depend on the project I am working on.
Quick Refresher just for anyone reading who is unsure what I mean by vertical and horizontal splitting of stories:
- ‘Vertical‘ user stories are user stories which take no account of the various layers of development which may exist in a project (DevOps tasks, Back End Tasks, Frone End tasks etc) – they simply state the story as viewed from the perspective of a downstream business user, expressing the business benefit that that audience will realise. Classic ‘As an X type of business user, I want Y type of feature so that Z business benefit’.
- ‘Horizontal‘ user stories are stories which recognise and call out the various layers which may be required as part of a wider story. This can often result in constructs such as ‘As a developer in Domain A, I want a technical feature from Domain B so that I can create Domain-A-related feature C’.
Earlier in my career I would have scolded myself for ever even considering horizontal slicing. Vertical slicing is generally the way that we’re taught is the ‘right’ way to express user stories. It’s the one which maps most easily to the INVEST model for writing stories which is so prevalent in the modern business analysis domain.:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Sized Appropriately
- T – Testable
However, some recent projects I’ve been on have forced me to re-evaluate that viewpoint – in particular, complex big data implementation projects which have a very high degree of technical tasking which maps to a very small number of identifiable end-user stories. In these projects, taking a vertical slice can be almost impossible, due to the depth of that slice (we’d end up breaking some user story rules, such as the concept that they should be deliverable inside of a sprint).
A Data Lake project for example might have some end user stories like ‘I want dataset X to be available in my BI workspace so that I can use it to calculate Report Y, providing the business with benefit Z’.
The problem here is that the user benefit itself appears relatively minimal, but the work required to deliver that dataset would in fact need to pass through many hands/domains.
- There’s probably an initial integration piece of work with the source platform.
- There’s the creation of the schema contracts for the incoming and outgoing data fields.
- There’s the ingestion of the source data into the data lake.
- There’s he staging of that data in a format and location which are useful to the analysts.
- There’s the setup and provisioning of all of the resources required for the above tasks via a repeatable DevOps pipeline into multiple environments
In a big business, some of these tasks are likely to be performed by different people/teams, all of whom already likely have other items in the queues. The possibility that this story might be delivered within a sprint therefore diminishes significantly.
Enter horizontal slicing. With this approach, we’d outline the business benefit at Feature level rather than Story-level (or, if using Jira, it can be helpful to move the abstraction to User Stories > SubTasks as there are board configurations which fit this approach quite well) – so we still get to use the INVEST model – it’s just that the sub-components themselves are more technical, and are there primarily to help the development team than the business stakeholders. Contentious, I know.
In summary, my preference will always be for Vertical slicing – it’s the easiest way to present business benefit back to stakeholders and track delivery of functionality. However, where required, I’m definitely now open to the concept of horizontal slicing on tech-heavy projects. To do otherwise is actually more likely to hold up the Agile process, particularly if a team’s intention is to follow the DevOps principle of improving flow from left to right across the board.
What do you think? Answers in the comments please 🙂