User Story “Slicing” For Technical Projects – It Isn’t A Piece Of Cake!

4 August 2017 | About a 8 minute read
Tags: blockchain, developer, Developers, DevOps, manager, process, Product, product analyst, slicing, tech, technical, technology, user story

At the outset you might be wondering “why should I even bother reading this blog when a simple Google search on user story slicing shows me over 350K results?”. The answer is simple: The idea here is to neither preach nor repeat the points that you have already read in several other blogs/articles. The idea instead, is to share my personal experience of working on a blockchain project (first of it’s kind here at AND Digital), the challenges I faced while writing and slicing user stories and how I changed strategy to make the stories decipherable for the developers, and valuable to the Product Manager. If that sounds interesting, then read on…

For the benefit of those who are unfamiliar with the term User Story Slicing, I will provide a simple definition:

User Story Slicing is a technique to split a large user story into one or more smaller user stories that are easy to implement. This can be done either ‘Horizontally’ i.e. by splitting the story by kind of work or architectural layers such as database layer, middleware, presentation layer, Testing etc. OR ‘Vertically’ i.e. by splitting across a cross section of all the layers but focussing only a small slice of functionality while delivering business value. You must have seen several diagrammatic representations of User Story Slicing using the layers of Cake analogy.

 With a little more web search you will find several techniques to perform effective “vertical slicing” that maximises the business value. The most popular ones being – slicing by workflows, by business rules and by operations (such as create, update, delete, etc.).

So now the question arises – If there are plenty of resources available out there, why is user story slicing considered so challenging? My answer to that would be: You don’t really know how well you can swim until you actually take a dip in the waters. I got the opportunity to take a dip, when I started working as an Analyst on this Blockchain project, three months ago.


The Challenge..

We started with an informative story mapping session with the Product Manager to understand his vision about the overall product and, in the process, created some epics and high level features that would fit under each epic. (good start yay!).

The next logical step was to gain traction by quickly writing some clear and crisp user stories that were really thin slices cutting across all the technical layers. Sounded simple enough? Well not quite! And here’s why:

When you are operating in an unknown and highly complex technical terrain such as blockchain, and that too for the first time, you are not quite sure what will be the simplest of user features such as; filling and submitting a registration form entail. So unless you are aware of all the layers you are going to cut through in that really ‘thin slice’, chances are you will end up writing a user story that deals superficially with the topmost layer only – since that is the only one you can perceive or really be clear about at an early stage of the project.

Thus, to unravel all those layers and demystify the complex technical interactions involved in order to accomplish just a rudimentary user function, it becomes absolutely imperative to perform some upfront technical analysis and system architecture work before you can actually start building any usable features.

And with that… our legendary epic was born that we proudly christened “Technical Scaffolding”. It was a bucket that we basically used to shove any and all technical tasks and stories such environment setups, network setups, spikes, devops tasks etc. – Nice and easy!


The Realisation…

Somewhere after the first Sprint Review and in the midst of Sprint 2, the realisation dawned upon us that so far none of the stories have been able to demonstrate any real “business value”. We learnt the hard way that regardless of the monstrous complexities and the technical conundrums, the ultimate goal of any software product is to provide some usable functionality/feature to the end user early on and often. There was a time when our Product Backlog was filled with disjointed technical stories, along with a few horizontally sliced user features here and there. We were quickly piling up a stack of functional but disconnected “technical” features that were hard to demonstrate, and didn’t exhibit any real business value.  The second Sprint Review raised the red flag for us. It called for an instantaneous change in strategy and this is how we approached it.


The Solution..

We came up with User Flows for the most important user journeys for the Minimal Viable Product (MVP) highlighting the key user interactions, and supplemented them with detailed Sequence Diagrams (with inputs from our blockchain expert) to highlight the interactions between various system components in order to complete each user journey. This helped clear the haze around the underlying blockchain architecture.

 Quick Tip: UML diagrams work nicely in conjunction with business process flows and user flows to unveil the technical complexities involved in implementing a feature/system functionality and also help estimating the user stories better.


Slicing Technique: In essence we used a blend of modified “slicing by workflow steps” AND “slicing by happy path” techniques to break down our user stories “vertically” with the following caveats:

  • Instead of a single straightforward workflow, we used a combination of User Flow and its corresponding Sequence Diagram to create our user stories
  • The stories we wrote were a mix of pure user stories and technical stories where each one aimed towards delivering a piecemeal functionality from the overarching workflow

We refined our Story Template (see the table below) and embellished it with some more details to add a bit more business context. This template worked well for both User and Technical stories

BENEFITS: Once we started applying the aforementioned approach, the benefits were almost apparent.

  • We were able to see and demonstrate tangible progress in terms of the work getting completed and the business value being delivered.
  • We were able to differentiate “must-have” from the ‘nice-to-have’ steps in the workflow and hence shorten the feedback loop by removing nice-to-have steps from the MVP.
  • With every passing Sprint, the team got better at slicing and estimating the remaining work
  • We were able to keep a check on the technical debt by focussing on and building only the most important features.


To summarise, here’s what I learnt about “user story slicing for technical projects”:

  1. It is okay to have some technical stories: Always add business context to a technical story to accentuate where it fits in the grand scheme of things along with the business value it offers.
  2. Maintain Requirements Traceability: While Requirements Traceability is a term widely used in traditional waterfall methodologies, the concept is applicable to Agile projects equally well. Sometimes we get so caught up in the technical nitty gritties that we tend to forget what we were building in the first place. Each user story must trace upwards to at least one of the high level business requirements/features.
  3. A little bit of horizontal slicing is okay: Yes, you read that right. It is okay as long as you know which piece of the puzzle it is completing. Sometimes it is just unavoidable in order to ensure constant flow of functionality and shorten the feedback loop. Just make sure you integrate a horizontal slice with preceding and succeeding layer constantly and seamlessly.
  4. Put some thought into the Acceptance Criteria: Always ask two questions while writing the Acceptance Criteria for a User or Technical Story: Can we test this? And can we demo this? If the answer is no.. think again.
  5. No one size fits all: When it comes to User Story Slicing, one size fits all doesn’t work. Select a technique that works best for type of product you are building, it’s technical complexity and the overall business objective. It might involve some additional analysis work but you will be happier in the long run.
  6. Don’t be scared of System Architecture: Try to gain some insight into what lies under the hood before you go deep into the story writing exercise. It will help you connect the dots and create better user story slices.


AND finally… Keep calm and continue slicing, until it really becomes a piece of cake for you! 🙂

Share this blog post

Related Articles


We’re looking for bright, dynamic people to join our team!

Discover More Roles