How eight proven story-splitting patterns turn 13-point sprint killers into vertical slices that actually ship value.
The agile-story-splitter Copilot Agent Skill applies Richard Lawrence's and Peter Green's eight battle-tested split patterns to break any oversized story into 2–5 sprint-sized vertical slices. Each slice's value is independent. No more "backend first, frontend later" horizontal cuts.
Source Code
The full skill implementation is available at:
GitHub - alwyndsouza/agile-story-skills
The Hidden Dysfunction at the Heart of Most Agile Teams
Agile transformations have been underway in software organisations for two decades. Scrum certifications are abundant. Story point poker is practically a professional sport. And yet, in refinement sessions the world over, teams are still doing something that silently undermines every agile principle they claim to follow: splitting stories horizontally.
It’s the default instinct. A story lands in the backlog that’s clearly too big — 13 points, six acceptance criteria, and a scope that spans the UI, the API, and the database. Someone in the room says the words: “Let’s just split it into backend and frontend.” Heads nod. The ticket gets cloned. Two new stories appear, and nobody notices that they’ve just recreated a miniature waterfall inside a sprint that was supposed to be self-contained.
This isn’t a competence problem. Most engineers and product managers understand agile in theory. The issue is that pattern recognition under time pressure defaults to technical decomposition — the mental model we use when we think about architecture — rather than value decomposition, which is the mental model agile actually requires.
I built the agile-story-splitter Copilot Agent Skill to address exactly this gap. But the more I've worked with it, the more I've come to see it as a symptom of a larger insight: the way we split stories reveals how we think about software delivery, and most of us have been thinking about it wrong.
Two Mental Models of Software Delivery
There are two fundamentally different ways to think about how software gets built and delivered.
The first is the layer model. In this view, a system is a stack — database at the bottom, business logic in the middle, interface at the top. Work flows downward: you build the foundation before you build the structure. This model is deeply intuitive for engineers because it mirrors how we think about architecture. It also maps neatly to organisational structures – backend teams, frontend teams, QA teams – which makes it feel like the natural unit of decomposition.
The second is the value model. In this view, a system is a collection of user-facing capabilities. Work is organised around capabilities, not layers. Each unit of delivery is a thin vertical slice that spans all layers and produces something a user can actually experience and react to.
The tension between these two models is the root cause of bad story splitting. When we default to the layer model — consciously or not — we produce horizontal cuts: stories that represent partial implementations of a capability across a single technical layer. When we apply the value model, we produce vertical slices: stories that represent complete, albeit narrow, implementations of a user-facing capability across all layers.
Imagine a five-layer cake. Cutting it horizontally gives you a plate of sponge, a plate of jam, a plate of cream — technically all the components of the cake, but none of them is a cake you can eat. Cutting it vertically gives you five smaller slices, each containing sponge, jam, and cream in proportion. Each is a complete, edible piece of cake. This is the difference between horizontal and vertical story splitting. Horizontal cuts produce components. Vertical cuts produce value.
The INVEST framework — Independent, Negotiable, Valuable, Estimable, Small, Testable — is the formal articulation of what a vertical slice looks like. A story that fails the “Independent” or “Valuable” criteria almost always does so because it’s a horizontal cut: a component that can’t be shipped or demonstrated without its counterpart layers. The framework is widely known. The failure mode it’s designed to prevent is still everywhere.
Why This Matters More Now Than It Ever Has
The argument for vertical splitting has always been theoretically sound. But I’d argue it’s become strategically urgent in the current moment for three reasons.
First, AI-assisted development is compressing implementation time. When it took a team a week to build an API endpoint, horizontal splitting was inefficient but survivable. When a capable engineer with Copilot can produce a working endpoint in hours, the coordination overhead of horizontal dependencies becomes proportionally more expensive. The bottleneck is no longer writing code — it’s integrating, validating, and shipping it. Stories that create dependencies between layers now consume more sprint capacity in coordination than they do in implementation.
Second, stakeholder feedback loops are shortening. Product teams are being asked to validate assumptions faster, to run tighter experiment cycles, and to get working software in front of users earlier. A story that can’t be demoed at the end of a sprint — because it’s waiting on its dependent layer — breaks the feedback loop entirely. Vertical slices are not just a delivery best practice; they’re a prerequisite for the kind of rapid validation that modern product development demands.
Third, AI tools are increasingly capable of enforcing standards at the point of work. The pattern knowledge that used to live in the heads of a few senior engineers — or in a Confluence page nobody reads — can now be embedded directly into the workflow as a skill that activates exactly when it’s needed. This is why building agile-story-splitter as a Copilot Agent Skill matters. It's not about automating story splitting; it's about making the right mental model available at the moment the wrong one would otherwise take over.
The Eight Split Patterns: A Decision Framework
The agile-story-splitter skill encodes all eight patterns from Lawrence and Green's Humanizing Work framework [6]. Each pattern addresses a specific structural reason why a story is too big. The skill auto-detects the best fit, but understanding the patterns transforms you from a tool user into a practitioner.
Think of the eight patterns as a decision tree. You begin by asking: what is the story actually describing? The answer — a user journey, a set of business rules, a data volume problem, and an uncertainty about technology — points you towards the right pattern. The pattern then gives you the cut lines.
P1: Workflow Steps
The most common pattern and the right starting point for any user-facing story. If the story describes something a user does, that doing almost always has sequential steps. Each step is a candidate for its own story.
Original: “User can complete checkout” Split: “User can add items to cart” → “User can enter shipping info” → “User can pay and confirm”
The instinct here is correct, and the pattern is forgiving. Even if the steps aren’t perfectly independent technically, they’re independent from a user-value perspective: you can demonstrate each one, get feedback on each one, and ship each one to a subset of users for validation.
P2: Business Rule Variations
Business logic is where conditional complexity accumulates silently. A story that says “apply discount logic” is hiding at least three different stories behind a single verb. Each business rule variation — each if condition in the logic — is a candidate for its own story.
Original: “Apply discount logic” Split: “Apply 10% member discount” → “Apply seasonal promo code” → “Apply bulk-order discount”
Splitting by business rule variation does something valuable beyond sizing: it forces acceptance criteria to be precise. You cannot write a good AC for “all discount logic". You can write one for “member discount applied at checkout".
P3: Data Variations
When a story contains the word “all” — import all customers, migrate all records, support all formats — it is almost always hiding multiple stories. Different data shapes bring different schemas, different validation rules, different edge cases, and often different regulatory requirements.
Original: “Import all customer data” Split: “Import US customer data” → “Import EU customer data” → “Import APAC customer data”
Beyond sizing, this pattern surfaces data-specific risk early. Discovering that EU customer data has GDPR implications after you’ve built a generic import mechanism is expensive. Isolating it into its own story forces the conversation to happen during planning.
P4: Acceptance Criteria Complexity
Sometimes a story is correctly scoped in concept, but its acceptance criteria are doing the work of three stories. When a single AC describes multiple independent behaviours — especially ones with additive complexity — each behaviour deserves its own story.
Original: “Search returns results with filters, sorting, and pagination” Split: “Search returns basic results” → “Search with filters and sorting” → “Search with pagination”
This pattern is particularly useful because it preserves the architectural coherence of the feature while giving the team room to deliver incrementally. Basic search ships first; the team gets real feedback on result quality before investing in filters and pagination.
P5: Major Effort
Some stories are large not because they’re conceptually complex, but simply because they involve a lot of repetitive or parallel work. Migrating a legacy system. Refactoring a module. Updating a data model across multiple downstream consumers.
Original: “Rebuild the reporting engine” Split: “Migrate report A to new engine” → “Migrate report B” → “Migrate remaining reports”
Splitting by effort does two things. First, it creates checkpoints: each migrated report is a demo, a validation that the new engine works, and a piece of evidence the approach is sound before committing to the full migration. Second, it makes the work visible in a way that a single 13-point story never does.
P6: External Dependencies
External systems — third-party APIs, partner integrations, vendor-provided SDKs — introduce a category of risk that internal architecture doesn’t: you can’t control the timeline, the reliability, or the interface. Isolating the integration into its own story contains that risk.
Original: “Integrate with payment provider” Split: “Set up payment provider sandbox integration” → “Implement live payment flow” → “Handle payment webhooks”
The sandbox story is particularly important. It time-boxes the discovery work — learning the API, understanding the authentication model, identifying edge cases — so that the live implementation story can be estimated with real data rather than assumptions.
P7: DevOps / Operational Steps
Operational work is systematically undervalued in backlog management. Deployment pipelines, monitoring dashboards, alerting rules, auto-scaling configuration — these are not finishing touches. They are first-class delivery requirements, and they deserve first-class stories.
Original: “Launch new service” Split: “Deploy service to staging with basic health checks” → “Add production monitoring and alerting” → “Enable auto-scaling and failover”
Treating operational steps as separate stories has a cultural effect beyond task management. It makes the operational requirements explicit and estimable, and it creates accountability: a story about production monitoring has an owner, an acceptance criterion, and a definition of done.
P8: Tiny Acts of Discovery
This is the pattern for unknown unknowns. When a story involves technology the team hasn’t used, an integration whose behaviour is undocumented, or an algorithm whose performance characteristics are untested, the correct response is not a wide-range estimate. It’s a spike.
Original: “Build ML recommendation engine” Split: “Spike: validate recommendation algorithm with sample data” → “Build MVP recommendation feature” → “Optimise and scale recommendation engine”
A spike is a time-boxed investigation with a specific output: enough information to estimate the subsequent stories. It’s not a story that can “fail” — any outcome that produces that information is a success. Treating uncertainty as a first-class story type is one of the most mature things an agile team can do.
The Pattern Is in the Story
The most important principle I’ve taken away from building and using this skill: you don’t reason your way to the right pattern. You read the story and let it tell you.
Picture the eight patterns arranged as a decision tree radiating outward from a central question: what is this story fundamentally about? Stories describing user journeys branch to P1. Stories hiding conditional logic branch to P2. Stories using “all” or “any” branch to P3. Stories with overlapping acceptance criteria branch to P4. Stories that are simply a large branch to P5. Stories touching external systems branch to P6. Stories with operational scope branch to P7. Stories containing uncertainty branch to P8.
Each path through the tree leads to a set of 2–5 candidate sub-stories, each of which is then validated against INVEST before being accepted. The tree is not a rigid algorithm — some stories will exhibit characteristics of multiple patterns, and experienced practitioners will develop a feel for which pattern produces the cleanest slices. But the structure matters. It replaces a vague intuition about “this story is too big” with a systematic interrogation of why it’s too big and where the natural cut lines are.
Embedding Intelligence Where Decisions Happen
The agile-story-splitter skill can be invoked in multiple ways:
GitHub - alwyndsouza/agile-story-skills
What Good Splitting Practice Signals About a Team
Teams that split well share a common characteristic: they think about delivery from the user backwards, not from the architecture forward. This sounds simple. In practice, it requires resisting a deeply ingrained instinct to decompose by technical boundary — the same instinct that makes engineers good at system design and makes them default to horizontal story splits.
The eight patterns are a translation layer between the way engineers naturally think about systems and the way agile teams need to think about delivery. A practitioner who has internalised them doesn’t need a skill to apply them — they’ve updated the mental model itself. The skill just makes that mental model available to everyone on the team, regardless of experience level, at the moment it’s needed.
That’s the real unlock. Not faster story splitting. A shared vocabulary and a shared standard for what “done” looks like at the story level — one that travels with the work rather than living in someone’s head.
References
[1] Alwyn D’Souza — Agile Story Skills — https://github.com/alwyndsouza/agile-story-skills
[5] Bill Wake — INVEST in Good Stories, and SMART Tasks — https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
[6] Richard Lawrence & Peter Green — Humanizing Work: 8 Patterns for Splitting User Stories — https://www.humanizingwork.com
Alwyn D’Souza is working at the intersection of data mesh architectures, MLOps, and agentic AI systems. He writes about modern data engineering and practical AI implementations on Medium at @aradsouza, shares open-source tools at github.com/alwyndsouza, and connects with the professional community on LinkedIn.
This article was originally published at https://aradsouza.medium.com/my-copilot-agent-skill-splits-stories-better-than-most-agile-teams-92c3130f1905?source=rss-670f6306e3c0------2