Disclaimer: There are probably a lot of cake related metaphors in this post, you might feel like ordering one by the end of this post, which is an unintentional side effect :)

A well-defined story

Creating well-defined stories is an essential part of software development nowadays, specially if you are following any of the “Agile” methodologies where the key motivation is to incrementally deliver value and at the same time building towards a goal or a product release.

One of the main ways to define a well-defined/good story is through the I.N.V.E.S.T. principle -

• I - independent - story should NOT be dependent on another story
• N - negotiable - scope of the story should be adjustable or negotiate how its implemented
• V - valuable - should provide business value
• E - estimable - enough clarity to be estimable
• S - small - small enough to provide quick feedback
• T - testable - independently verifiable and testable

This principle is generally a guiding principle, not exactly a strict rule and, it is important that we keep this in mind when discussing how a story is sliced/defined.

Preface - Iteration 0

At a very abstract level, majority software product development (from scratch) starts with -

• Infrastructure setup - cloud provisioning, infra-as-code …
• Skeleton/scaffolding code setup - using best practices for the language/framework …
• CI/CD - path-to-production - including steps like code analysis, testing, building and deployment …
• Observability/monitoring/alerting/logging setup …

In brief, we are setting the foundation of the project so that it is production ready from day one.

So, we’ve not built any actual software for the problem statement which delivers value.

Usually what I’ve seen is that teams spend a lot of time refining these steps as the project goes along and with increasing infrastructure complexity (viz. microservices, kubernetes, cross-platform apps), the effort spent in this is significant.

The clarity that this begs is how the business value is or might be perceived differently by a tech-savvy vs a non-tech-savvy business or customer and how much are we willing to shed in terms of delivering the best-in-class software engineering.

An Alternative View - Story Slicing

Given that we do not want to compromise on engineering excellence and what is considered best-in-class, the question is how these tasks are then tied into the whole “deliver business value” theme.

One way of looking at this is how we slice a story (the whole project/product/scope being the cake metaphor).

There are 2 ways of slicing a story -

• vertically - like majority of folks would normally eat a cake, by slicing vertically into individual pieces, or

• horizontally - maybe not so majority who like the icing layer or the fruit only layer :D

Right Way To Start - Vertical or Horizontal ?

In an ideal world, vertical slicing would be the right way to slice stories as they provide the complete value (think eating all the layers of the cake together, not just a single layer of the icing). This is how we deliver business value at the end of the day.

But let’s flip the cake metaphor the other way around - do we build cakes vertically ? or horizontally ?

When you think of it this way, the point that becomes clear -

Enough Horizontal Layers need to be built before we can start to Vertically start building something

This idea ties back to our I-0 tasks - if we try to incorporate those horizontal layers into the stories directly and try to make it a vertical slice, we will end up having really large stories that incorporate too many things and violate the INVEST principle.

Business Value - Horizontal Slicing

But you might be thinking - doesn’t the horizontal slicing also violate the INVEST principle ?

Delivering fast business value is the promise of Agile but if we keep building these horizontal layers for a long time, there is really no actual business value in the eyes of the stakeholder who is paying for the project - all they are seeing is dashboards and pipelines.

The key point that I find here is to how to show all the stakeholders - tech and non-tech - that this is actually value, not necessarily something that they can see as a web page or an app feature but as a foundational step to building a production ready application.

To build a software system/product of good quality, the expectation needs to be set amongst all stakeholders about how long it will take to build the horizontal slices and also articulate how those slices add up to form the final picture.

Trade-Offs - Speed, Quality, Scope

There’s this famous saying - that you can only 2 of 3 things - speed, quality, scope - you’ll have to trade-off on one point.

• Speed or pace of development is usually directly constrained by the problem space - in how streams of work it can be parallelized into.

• Scope & Quality - these two directly translate to prioritization - what’s important right now and what can be done later.

Increasing Detail In Horizontal Slicing

When we define our horizontal slices, I’ve usually seen only business stories being subject to these constraints. Increasingly, I feel that the foundational and cross-cutting stories should also be subject to these constraints of speed, quality and scope.

On the basis of these constraints, we should prioritize the horizontal slices in a way that aligns with how want to deliver business value.

Summary

There is no right answer here as you might expect - it’s always a constant learning experience on how to define, scope and prioritize, and I hope this gives the reader a new view point on how a story could be sliced.