This post lays out a practical way to spot oversized, fuzzy stories and use AI to split them into vertical, end-to-end slicesthat ship value—without turning your board into a graveyard of chores. The examples assume Battra, but the approach applies anywhere.

The Smell Test: “Big Story” vs. “Non-Story”

A real story should pass a simple 5-point sniff test:

1. User-observable (demoable behind a flag counts).

2. Valuable (changes a user behavior or outcome).

3. Independent enough to complete without cross-team choreography.

4. Small (1–3 days of elapsed work for a pair/small swarm).

5. Testable (clear acceptance criteria).

Fail any two of these and you’re likely holding a big story or a non-story (role/tech slice).

Common anti-patterns:

• Team splits: “Frontend,” “Backend,” “QA,” “Docs.”

• Architecture splits: “DB migration,” “API endpoint,” “React component.”

• Burndown theater: Lots of movement on tiny tasks, nothing demoable.

The Reframe: Split by Outcomes, Not Org Charts

Good splits are thin, end-to-end verticals. Think “walking skeleton”: deliver one narrow path that works from UI through storage and back, even if it’s rough and behind a flag. Then add more narrow paths.

Useful axes for splitting by outcome:

• Persona / Role: admin vs. employee vs. contractor

• Trigger / Context: web vs. mobile, first-time vs. returning

• Variant of the capability: Google login vs. email/password vs. magic link

• Workflow stage: happy path → error handling → edge cases

• Risk first: de-risk an unknown (external API, compliance) as a separate slice

• Data slice: one product line/region/currency before all

• Rollout stage: internal users → beta cohort → general availability

Pick one or two axes to start. If a split doesn’t produce something demoable, it’s not a story—merge it back.

Example: The “Login” Mega-Story

Big story: “As a user, I want to log in so I can perform privileged activities.”

Bad (non-story) splits

• “Create login page (frontend)”

• “Auth endpoints (backend)”

• “User table (database)”

• “QA test login”

Each depends on the others; none is user-complete.

Better, vertical splits

1. Google login (internal users only, behind a flag)
   AC: Internal users can authenticate with Google; success leads to a basic “Timesheet” page; failures show friendly error; event logged; telemetry visible.

2. Email/password happy path (flagged)
   AC: Existing seeded users can log in; can log out; p95 < 200ms; audit log writes.

3. Magic link (edge case + a11y copy)
   AC: One-time links expire in 15 minutes; keyboard-only flow passes.

4. Error handling & rate limit
   AC: Lockout after N attempts with reset instructions; 429 surfaces; alarm on brute-force signal.

5. Rollout to external cohort
   AC: Feature flag to 10% external users; kill switch; docs updated.

Each slice is demoable, testable, and safe to ship behind a flag.

Why Humans Struggle (and Where AI Helps)

Humans tend to mirror their org chart: “I do backend, so the story is an API.” Under pressure, we also over-optimize for motion (lots of tickets moving) instead of flow (value finishing).

AI can help by:

• Recognizing non-story language (“create,” “set up,” “implement”) vs. outcome language (“user can…”).

• Extracting persona, capability, value from a big story and proposing vertical splits along meaningful axes.

• Generating acceptance criteria and test notes per slice.

• Flagging risk hotspots (e.g., “SSO provider unknown; propose capability probe slice”).

• Replacing the big story with an epic + linked end-to-end stories (or a single story with a checklist if that’s truly better).

What AI-Assisted Splitting Looks Like (in practice)

Input (the “too big” story):

“As a user, I want to log in so that I can perform privileged activities.”

AI proposes (example output):

Epic: User Authentication (MVP)
Goal: Enable secure authentication for employee timesheets with staged rollout.

Stories:

1. Login with Google (internal, flagged)

   • AC: Internal user can authenticate via Google; redirected to Timesheet; errors are actionable; event auth.login.google.success/failure recorded; feature off by default.

   • Test notes: Seed one internal Google account; synthetic telemetry check.

2. Timesheet access gated by session

   • AC: Timesheet page redirects to login if session missing/expired; logout works; session TTL 24h; audit trail recorded.

   • Test notes: Simulate expiry; verify redirect chain.

3. Email/Password happy path (seeded users only, flagged)

   • AC: Seeded users authenticate; password policy enforced; basic lockout after N failures (no UX polish yet).

   • Test notes: Brute force simulator; ensure alarms.

4. Error handling & a11y

   • AC: Tokens expire gracefully; screen reader labels present; keyboard flow passes.

   • Test notes: VoiceOver/NVDA pass.

5. Rollout control

   • AC: Gradual enablement (0% → 10% → 100% for internal; beta cohort for external); kill switch; on-call playbook.

AI also suggests:

• Reject these non-stories if created: “Create user table,” “Implement OAuth client” (fold them into the vertical slices).

• Risk slice: “SSO capability probe” if identity provider is unknown.

This is the difference between shipping and assembling parts.

Heuristics the AI Uses (transparent rules you can teach)

1. INVEST guardrails: If a candidate slice isn’t Independent, Valuable, or Testable, merge it back.

2. Demo rule: Every slice must be demoable to a real or fake persona (internal is fine) behind a flag.

3. Two-axis max: Prefer splitting on one primary axis (e.g., capability variant) and one safety axis (e.g., rollout stage). More axes → explosion of tickets.

4. Risk-first slice allowed: If something is unknown (3rd-party API limits, compliance, perf), create a capability probe slice whose output is knowledge + a thin working path.

5. Checklist, not child tickets: Sub-activities (migrations, copy polish) become PR/story checklists unless they genuinely require separate validation.

Replace Child Tickets with Smart Checklists

Keep flow tight by embedding detail inside the story/PR:

### Acceptance Criteria
- [ ] Internal users can log in with Google and reach the Timesheet
- [ ] Failure states provide actionable guidance (no vague “Error”)
- [ ] Telemetry: auth.login.google.{success,failure} captured
- [ ] Feature flag default OFF; kill switch documented

### Done Definition
- [ ] Unit + integration tests for happy path
- [ ] Dashboard panel shows success/failure rates
- [ ] Alert on 5-minute failure rate > 5%
- [ ] a11y: focus order and labels verified

Export these checklists to your audit system after merge if you need paper trails. Don’t fragment development to create them.

Prompt-First Workflow (so splitting happens at the right moment)

1. Declare intent once (CLI, editor, or chat):

    Split the big story "As a user, I want to log in so I can access timesheets"
   

2. AI proposes an epic and 3–5 vertical slices with AC, risk notes, and rollout.

3. You prune (merge or delete) and accept the slices.

4. Tool replaces the big story with the epic and linked stories, seeds PR templates, and sets flags.

5. Board policy: Only stories move columns. Checklists live in the PR; no role-sliced tickets.

This keeps humans in control of intent, with the AI doing the clerical heavy lifting.

Metrics to Prove It Worked

Expect to see improvements in:

• Lead time per story (request → production behind a flag)

• Review latency (PR open → first review)

• Aging WIP (stories > N days in progress)

• Change failure rate (thin, end-to-end changes tend to fail less)

• % of stories demoable per sprint (no more “done backend” without a path)

Stop counting subtasks; start measuring flow.

Pitfalls (and how the AI avoids them)

• Explosion of tiny stories: Use the two-axis max heuristic and combine micro-splits into a single outcome slice.

• Hidden dependencies: The AI tags slices with “shared concerns” (e.g., session store, email provider) and warns if a slice can’t be demoed without them.

• Gold-plating early: Early slices bias to happy path behind a flag; polish and a11y get their own slice once the path exists.

• Reintroducing team splits: The bot gently blocks story titles that start with “Backend/Frontend/QA” and suggests a vertical rewrite.

A 30-Minute Starter Plan

1. Add the sniff test to your story template (“Demoable? Valuable? Independent? Small? Testable?”).

2. Pilot AI-assisted splitting on your next obviously-big story (e.g., “Login,” “Invoicing,” “Search”). Accept 3–5 slices max.

3. Change board policy: Only stories move columns; checklists live in PRs; ban role-sliced tickets.

4. Feature-flag everything so thin slices can ship safely.

5. Measure two sprints of lead time and review latency. Share the deltas at retro.

TL;DR

Most “splitting” turns stories into role-based chores that don’t ship value. Teach your system (and your team) to split by user-visible outcomes along a couple of sensible axes—persona, capability variant, workflow stage, risk—so each slice is end-to-end, demoable, and testable. Let AI do the mechanical work: detect non-stories, propose vertical slices with AC, replace the mega-story with an epic + linked stories, and keep the board focused on flow.

That’s how you make splitting useful: fewer chores, more value, shipped sooner.

This post explores why hierarchical UIs waste so much time, what kinds of confusion teams typically face, how enforced integrations make the problem worse, and what a prompt-first, opinionated assistant does differently.

The Thirty-Minute Treasure Hunt

A typical situation: a developer is told to “finish the payment error story.” They open the tool and search payments error. Up come dozens of results:

• An epic called “Improve Checkout Reliability.”

• A story called “Handle decline codes from providers.”

• A subtask named “Update error mapping table.”

• A linked bug “iOS app shows generic error.”

• Another story “Retry transient errors.”

Which one is the right one? The only way forward is to click through them all, read the comments, and try to piece together the intent. What should be a two-minute lookup becomes a 30-minute focus-breaking hunt.

Why Hierarchies Turn Into Mazes

Naming Drift

Epics and stories often share similar titles—“Payments Error,” “Handle Payment Errors,” “Error Handling Improvements”—that overlap without clarifying.

Depth for Depth’s Sake

Some teams use epics as themes, others as oversized stories. Subtasks may be detailed technical work or placeholders. There is no consistency.

Too Many Links

“Blocked by,” “Relates to,” “Clones,” “Duplicates”… after a few months, the web of links looks official but doesn’t guide action.

Search That Doesn’t Help

Search matches text literally. If you don’t guess the right wording or ID, you’re spelunking.

Typical Planning Session Confusion

During planning, a product owner pulls up an initiative: “Mobile App Performance.” Inside sit 12 epics. One epic, “Improve Load Times,” has 18 stories, each with subtasks.

Leadership asks, “Which of these have actually shipped?”
The PO clicks through epic after epic, but there’s no clear signal. Everyone is left with lots of data but no answers.

This isn’t an outlier—it’s a common planning pain.

The Developer’s Daily Grind

• Context-switching penalty: Multiple tabs open, each for a different branch of the hierarchy.

• Guesswork navigation: Without story IDs, devs send Slack messages like “Is it S-142 or S-187?”

• Incomplete parent items: Subtasks show as “Done,” but the user-visible story is still waiting.

The result: developers rely on colleagues for navigation instead of trusting the board.

The Product Owner’s Parallel Pain

• Endless grooming: Sorting, renaming, merging duplicates.

• Shadow systems: Because grooming feels hopeless, many POs keep the “real” priorities in Notion or Excel.

• Update stress: When asked, “What shipped?” they know it will take several clicks and hedging, not a confident answer.

Stakeholders and Sponsors: Simple Questions, No Simple Answers

Executives rarely dive into the tool. When they do, they face a tangle. Their questions are straightforward:

• “What’s blocking the iOS checkout release?”

• “Which parts of the security epic are still open?”

• “What shipped last week?”

The hierarchy can’t answer those questions clearly. It was designed for structure, not for outcomes.

When Git Hooks Make It Even Worse

Many organizations try to enforce discipline by wiring their version control system to their agile tool. A common pattern: every commit message must reference a valid ticket ID, and the ticket must be in the correct state. If it isn’t, the push is rejected.

On the surface, this seems sensible: traceability between code and work items. In practice, it multiplies the pain of hierarchies.

Imagine finishing a feature branch with six commits:

• fix error message fallback

• add test coverage for provider X

• retry transient errors on timeout

When you push, the hook blocks:
“Commit must reference a valid ticket ID in an In Progress or In Review state.”

Now the developer must:

1. Identify which ticket each commit belongs to.

2. Navigate the hierarchy to find the correct ticket IDs.

3. Check if the ticket is in the correct state; if not, move it.

4. Rewrite six commit messages to append IDs.

5. Push again.

A task that should take seconds becomes 20 minutes of clerical work. Worse, if the wrong ticket was chosen, the traceability is meaningless anyway.

Instead of creating alignment, enforced hooks amplify the cost of poor hierarchies. They punish developers for the tool’s complexity.

Why Teams Tolerate It

• It’s the norm. Everyone has grown used to the idea that hierarchies are “just how agile tools work.”

• Inertia. Years of epics, subtasks, and custom workflows make teams hesitant to simplify.

• Fear of losing detail. Leaders think fewer levels means losing oversight, even though the detail is already buried.

• Compliance theater. Hooks and integrations create an illusion of control, even when the quality of the data is questionable.

The Prompt-First Alternative

Instead of spelunking through boards—or fighting hooks—you ask the system directly:

• “Show the story blocking checkout for iOS, owned by Payments, estimated under 2 days.”

• “What shipped in the last 7 days that touched authentication?”

• “List all open high-priority mobile bugs.”

The assistant surfaces results ranked by:

• Code ownership (which service or repo was touched).

• Recency (recent commits and activity).

• Release linkage (what is tied to an actual shipment).

And for git integration:

• Commits auto-link to the right work item, inferred from branch name, PR context, and test coverage.

• If the match isn’t obvious, the assistant prompts: “These commits look related to Story S-142 (Checkout Errors). Link them?”

• Instead of push-blocks, developers get lightweight suggestions.

Opinionated Guardrails That Prevent the Maze

• Limit nesting. Epics and stories are enough. Subtasks appear automatically when code is linked.

• Detect duplicates. New stories flagged as similar to existing ones trigger a merge suggestion.

• Force clarity. Duplicate titles aren’t allowed; stories require outcomes.

• Archive stale work. Items untouched in 90 days snooze unless re-affirmed.

• Smarter git hooks. Enforce links without punishing developers—auto-suggest IDs, move tickets based on repo events.

A More Typical Workflow With Prompts

• A developer asks: “What’s the next bug in Payments under 4 hours of work?” → The assistant proposes two ranked options.

• A PO asks: “Show me everything at risk of missing the sprint goal.” → The assistant surfaces stories with PRs stuck in review.

• A sponsor asks: “What shipped to customers this week?” → The assistant lists three stories tied to releases, with user-visible outcomes.

No tree-digging. No guessing. No rewriting commit messages after failed pushes.

The Ripple Effects

• Developers: Hours saved per week, flow protected, less tool resentment.

• Product Owners: Less grooming, more prioritization.

• Sponsors: Clearer answers tied to outcomes, not IDs.

• Leads: Traceability achieved automatically, without punishing hoops.

Takeaways

Ticket hunting is not productive—it’s bureaucracy disguised as organization. Hierarchies encourage wandering, and enforced git hooks amplify the waste by turning commits into paperwork.

A prompt-first, opinionated assistant cuts through the maze. Ask what you need, and get context-ranked answers. Link code to work automatically, not by forcing humans to append IDs.

Agile promised speed and focus. To get there, we need tools that answer questions and automate traceability, not ones that bury both in structure.

Instead of being a tool that quietly supports flow, Jira often dominates the working day — dictating what a product owner or developer can do, when they can do it, and how many hoops they must jump through to do something simple.

This isn’t just inefficient. It actively works against agility.

A Day in the Life: Product Owner

Imagine you’re a product owner preparing the next sprint. You should be focused on vision and value: clarifying what the team should deliver and why. Instead, here’s what often happens:

1. Field Fatigue. Every new story demands that you fill in a dozen fields: “Epic link,” “Component,” “Business Unit,” “Priority Matrix,” “Regulatory Category.” Some of these may never be read by anyone, but they’re enforced, and the ticket won’t save without them.

   One PO I know spent fifteen minutes hunting down the right value for a “Risk Classification” dropdown with thirty options. The story was about fixing a typo on a marketing page.

2. Workflow Wrestling. Want to move a story from “Ready” to “In Progress”? Not so fast — the workflow has three intermediate states. Each requires you to set flags or checkboxes. Miss one, and the story is rejected with a cryptic error.

   Another team was blocked for half a day because a ticket couldn’t leave “Analysis” until the “Change Advisory Board” field was completed. The CAB wasn’t even relevant to their team — it was a global requirement inherited from another department.

3. Backlog Bloat. Jira doesn’t care if you write a monster story that could take a month. In fact, it encourages it — epics, sub-tasks, linked stories. The backlog balloons into an overgrown forest, where grooming is less about clarity and more about compliance.

Instead of thinking about customers, the PO spends much of their time playing form-filler-in-chief.

A Day in the Life: Developer

Now imagine the developer picking up one of those stories. They’re ready to deliver some value. But again, Jira gets in the way:

1. Ticket Tetris. Before they can even start, the developer must navigate the ticket’s fields. Is the “Environment Impact” filled in? Has the “Compliance Risk” flag been set? If not, they can’t transition the ticket, and they’ll need to chase the PO.

   I’ve seen developers give up on starting work because they didn’t have permission to edit the required “Cost Centre” field. They literally couldn’t press the “Start Progress” button without waiting for finance to update it.

2. Push Blockers. Later, when they open a pull request, the integration checks whether the Jira ticket is in the “In Review” state. If it isn’t, the PR is blocked. The developer must context-switch out of GitHub, update the Jira ticket, and re-push.

   One engineer told me their PR was blocked three times because the ticket was in the wrong sub-state: “Code Review,” not “Peer Review.” Both meant the same thing — but Jira didn’t care.

3. Time-Tracking Tax. At the end of the day, they must log hours against each ticket. This isn’t used to improve flow — it’s often just to satisfy management reports. But if it’s missed, the system nags them or even locks their sprint board.

   In one large enterprise, developers were forced to split their hours across multiple “billing codes.” A two-hour bug fix might be logged as 0.5h “Maintenance,” 1h “Change Request,” and 0.5h “Unplanned Work.” None of it helped them deliver faster — but it satisfied an Excel sheet somewhere.

By the time actual coding happens, the developer has already invested significant time simply satisfying Jira.

The Root of the Problem

Jira wasn’t designed to be a lightweight, opinionated tool. It was designed to be infinitely configurable — to suit every team, every enterprise workflow, every PMO demand. But that flexibility comes at a cost:

• Bureaucracy by Default. If a field can be added, it will be. If a workflow can be extended, it is.

• Anti-Pattern Reinforcement. Large, vague stories? Jira supports them. Waterfall disguised as agile? Jira accommodates it.

• Cognitive Overhead. Developers and POs must constantly remember which fields matter, which states are valid, and how to game the system to keep work flowing.

Instead of helping teams be agile, Jira often enforces the illusion of control while consuming real time and energy.

An Opinionated Alternative

Our philosophy is different: less choice, more clarity.

We believe a tool should guide you toward good agile practice, not let you reinvent bureaucracy. That’s why our assistant is opinionated:

• Simplified Workflows. A story can only be Ready, In Progress, In Review, or Done. That’s it. No labyrinth of states to navigate.

• Healthy Story Size. Try to create a story that’s too big? The tool will stop you. Stories must represent small, testable slices of value.

• Automated Hygiene. Forget moving tickets. If a PR is merged, the story progresses. If tests fail, it rolls back. The board reflects reality, not admin activity.

• No Dead Fields. You’ll never be blocked by an irrelevant enterprise checkbox. Fields are lean and purposeful, designed for teams, not auditors.

This isn’t about restricting freedom. It’s about protecting flow. Teams are freed to focus on delivering, not filling forms.

Where AI Helps

AI isn’t the headline — it’s the quiet partner reinforcing the opinionated design.

• Spotting Story Smells. If a story looks too large or unfocused, the assistant suggests splitting it.

• Clarifying Acceptance Criteria. Developers don’t start from a blank page. The assistant drafts criteria aligned to agile best practice.

• Context Awareness. If a “story” is really a “task,” the assistant nudges you to reframe it.

• Automatic Linking. PRs, tests, and stories are connected automatically, without developer intervention.

AI isn’t there to overwhelm. It’s there to reduce friction and keep work flowing.

The Human Impact

The biggest difference isn’t just fewer clicks — it’s cultural.

• For POs: More time thinking about customer value, less time in field validation purgatory.

• For Developers: More time coding, less time chasing ticket states.

• For Teams: A shared board that reflects reality, not compliance.

When the tool is opinionated enough to prevent bureaucracy, and intelligent enough to smooth the edges, teams rediscover the agility they were promised in the first place.

Conclusion

Jira feels like bureaucracy disguised as agile because it allows — and often enforces — process that serves the tool, not the team. It turns product owners into administrators and developers into compliance officers.

We believe there’s a better way: an opinionated, constraint-driven assistant that actively prevents bureaucracy from creeping in. One that makes the right way the easy way, and quietly uses AI to handle the rest.

Because agility shouldn’t be about managing Jira. It should be about delivering value.