Splitting user stories: Are you doing it right?

Why Story Splitting Matters

A well-split user story allows teams to deliver value faster, gather early feedback, and reduce risks. However, not all story splits are created equal. Some provide incremental, usable functionality, while others create dependencies that slow down progress.

One of the most effective ways to split stories is by following the user’s workflow. But how do you know if you’re doing it right?

10 Questions to Assess Your Story Splitting using user journey:

Before deciding how to split a story, ask yourself these key questions:

1. Do we have an automated deployment pipeline?
2. How frequently can we get feedback from real stakeholders?
3. Does each step deliver something usable and testable for the user?
4. Can the user interact with this step independently?
5. Can the user reach a meaningful stopping point after this step?
6. Does this split touch all necessary layers (UI, backend, database)?
7. Can the next step be developed independently?
8. Does the story focus on a full user action, not just a backend, UI, or database task?
9. Can a user interact with this step before needing the next one?
10. If this step was deployed, would the user find it useful, even if the full workflow isn’t done?

If you answer “no” to most of these, you might be splitting user stories horizontally rather than vertically.

A user’s journey from start to finish offers an effective way to split stories. Using story maps creates this sequential thinking framework, but remember – not every identified step needs implementation. While the path follows a sequence, each user action can be accomplished through multiple approaches.

Here are the top 5 signs that indicate you’re splitting stories horizontally using user journey steps:

1. Stories lack end-to-end functionality and don’t deliver independent user value. Even if it delivers partial value, it is fine.
2. Dependencies exist between stories, where one cannot be completed without another.
3. Stories are broken down into set of tasks, technical layers, components, or UI rather than outcomes.
4. Difficulty demonstrating tangible progress or value to stakeholders after completing a story.
5. Stories are written from a specific perspective (e.g., “As a programmer, I want…”) rather than a user or stakeholder perspective.

Strategic Decision-Making for Story Splitting:

A lot of times the user journey is complex and sequential, making it challenging to complete everything in a single sprint. What do you do then ?

It is the balancing act of whether the outcome could be achieved incrementally or iteratively. They are not the same. When splitting user stories, it’s not always possible to achieve iterative value, especially when dealing with workflow steps that are dependent on each other. In such cases, the splitting often results in incremental value instead. This is a common scenario in software development, and it’s important to recognize the difference.

In the presence of uncertainty iterative approach is best but it really depends on whether the goal is reducing risk or cost of delay.  Usually, iterative approach is more leaning towards minimizing the queue size and cost of delay, however the feedback loop from idea to market should be effortless. Which also you have direct engagement with real users or stakeholder and the automated DevOps pipeline is in place which can ship product with simple toggle.

Principles for splitting vertically when splitting via user workflow:

1. Create a thin, end-to-end slice: Focus on delivering a minimal but complete workflow that covers all steps, even if functionality is limited at each stage.
2. Implement incremental sophistication: Start with the simplest version for each step, even though each step adds partial value.
3. Use stubs or mocks: For steps dependent on previous ones, use simulations to represent outputs of incomplete steps.
4. Break down further: Identify even thinner slices that can be completed within a sprint.
5. Accept multi-sprint stories: If a minimal end-to-end flow spans multiple sprints, clearly define the overall goal and break it into sprint-sized chunks that still deliver tangible progress.

In agile product development, we often aim for iterative value through vertical slicing of user stories. However, when dealing with complex, sequential workflows, we may find ourselves in a situation where true vertical slicing becomes challenging. This often results in an incremental approach, where each story represents a step in the workflow, but may not provide standalone value until the entire feature is complete. While this incremental approach can delay value realization, it’s sometimes unavoidable due to the nature of the work. In such cases, it’s crucial to focus on creating the smallest possible increments, maintaining end-to-end visibility of the workflow, and seeking opportunities for feedback even on partial implementations. Communication with stakeholders becomes paramount to manage expectations about delayed value delivery. Despite the incremental nature, teams can still apply iterative principles within each increment, refining and improving as they progress towards the complete feature.

When ‘Not’ to Split Stories, would like to call them Value token’s?

While story splitting is generally beneficial, there are situations where it can be counterproductive:

1. High Transaction Costs: When the overhead of deploying each story is significant, splitting stories too finely can lead to excessive costs. For example, if each deployment requires extensive manual testing and approval processes, the time and resources spent on these activities for numerous small stories may outweigh the benefits of splitting.

2. Increased Queuing Time: Without automated deployment, smaller stories may spend more time in queues, leading to delays in feedback and value delivery. This can result in a situation where many small, completed stories are waiting for deployment, but users aren’t benefiting from any of them.

3. Loss of Context: Overly granular stories may cause developers to lose sight of the bigger picture, potentially leading to suboptimal design decisions or missed opportunities for optimization

The key is to balance the benefits of smaller stories with the economic realities of your development and deployment processes. Without automation, smaller story increments may sit in queues longer, creating invisible bottlenecks that delay feedback loops and overall delivery. This delay amplifies economic losses as businesses fail to realize the value of completed work promptly. Reinertsen emphasizes quantifying trade-offs, such as the cost of delay versus risk reductio,n to make informed decisions, as unmanaged queues and delays are key drivers of poor economic performance in product development

Ref: D. Reinertsen’s work