SERIES: AI-POWERED DEV WORKFLOW · POST 6 OF 10
Sprint planning used to eat half my Monday. Writing tickets, breaking stories into tasks, figuring out the right level of granularity, adding acceptance criteria, linking dependencies. By the time the team was actually ready to start work, half the morning was gone.
The FRD already has everything Jira needs. User stories are right there. Acceptance criteria are right there. Dependencies between features are right there. Claude just needs to read it and restructure it into tickets. This post shows exactly how to do that — including pushing directly to Jira via the MCP so you never touch the Jira interface at all.
The Jira Hierarchy You Should Be Using
Before generating anything, it helps to have a clear mental model of the hierarchy. A lot of teams mix these up and end up with stories that are actually epics, or tasks that should be stories. Here is how I use them:
| Level | What it represents | ClientHub example |
|---|---|---|
| Epic | A major feature area. Usually spans multiple sprints. Maps to one functional area of your FRD. | Authentication and Role System |
| Story | A user-facing capability. Deliverable in one sprint. Maps to a user story in the FRD. | User Login, Forgot Password, Role Assignment |
| Task | A specific unit of technical work. One developer, one or two days. No user story needed. | Build POST /auth/login endpoint, Implement JWT session management |
| Sub-task | Optional. Use for tasks that genuinely need splitting — e.g. separate frontend and backend work on the same task. | Use sparingly. Most teams over-use sub-tasks. |
The Four-Step Prompting Strategy
Work top-down: epics first, then stories, then tasks. Do not try to get everything in one prompt. One prompt per level gives you a chance to review and correct before Claude builds the next level on top of it.
Step 1 — Extract Epics from the FRD
PROMPT 1 - Extract Epics
Read docs/ClientHub-FRD-v1.md.
Identify all Epics. An Epic maps to one major functional area
of the FRD. Each Epic should be deliverable across 1-3 sprints.
For each Epic, output:
- Epic name (short, noun-phrase)
- Description (1-2 sentences)
- FRD sections it covers
- Rough story point estimate (Fibonacci: 8 / 13 / 21)
- Dependencies on other Epics (if any)For ClientHub, Claude identified six Epics: Authentication and Role System (13 pts), Project Management (8 pts), Deliverable Approval Workflow (13 pts), Notification System (5 pts), Invoicing and Invoice Dashboard (8 pts), and Audit Logging (5 pts). That mapped cleanly to the six functional areas in the FRD.
Step 2 — Break Each Epic into Stories
PROMPT 2 - Generate Stories for an Epic
For the "Authentication and Role System" Epic, generate all Stories.
Each Story must:
- Be completable within one sprint
- Be written as: "As a [role], I want to [action] so that [outcome]"
- Have 3-6 acceptance criteria (specific, binary, testable)
- Have a story point estimate (1 / 2 / 3 / 5 / 8)
- Note any other Stories it depends on
Do not generate tasks yet. Stories only.Step 3 — Break Each Story into Tasks
PROMPT 3 - Generate Tasks for a Story
For Story CH-2 (User Login), generate the development Tasks.
Each Task must:
- Represent concrete technical work (not a user story)
- Be completable by one developer in 1-2 days
- Have a clear title that describes exactly what gets built
- Note any other Tasks it depends on within this Story
Cover: API, frontend, business logic, tests.Step 4 — Rough Point Check
PROMPT 4 - Point Check and Review
Review the full Authentication Epic with all its Stories and Tasks.
Check:
1. Are any Stories too large for one sprint? (over 8 pts = split it)
2. Are there any missing Stories based on the FRD?
3. Are dependencies correctly ordered?
4. Does the total Epic estimate still make sense?
Flag any issues. Do not rewrite yet — just list what needs attention.The Full Example: Authentication and Role System Epic
Here is what the complete ticket hierarchy looks like for ClientHub after running Prompts 1 through 3. Story CH-2 (Login) is shown in full because it is the most instructive:
EPIC · Authentication and Role System · 13 pts
STORY · CH-1: User Invitation and Registration · 3 pts
STORY · CH-2: User Login · 5 pts
TASK CH-2.1: Build POST /auth/login API endpoint
TASK CH-2.2: Build login form with field-level validation
TASK CH-2.3: Implement JWT generation and 24h session expiry
TASK CH-2.4: Account lockout after 5 failed attempts
TASK CH-2.5: Write unit tests for auth service
STORY · CH-3: Forgot Password and Reset Flow · 3 pts
STORY · CH-4: Role Assignment by Admin · 2 ptsAnd here is Story CH-2 in full ticket format, exactly as it would appear in Jira:
| Field | Detail |
|---|---|
| Ticket ID | CH-2 |
| Type | Story |
| Epic | Authentication and Role System |
| Summary | User Login |
| User Story | As any registered user, I want to log in with my email and password so I can access my account and projects. |
| Story Points | 5 |
| Acceptance Criteria | 1. Login form accepts email and password fields. 2. Valid credentials redirect user to /dashboard. 3. Invalid credentials show inline error under password field; no page reload. 4. After 5 failed attempts within 10 minutes, account locks and a reset email is sent automatically. 5. Locked account shows message: “Account locked. Check your email for a reset link.” 6. Session token expires after 24 hours; user redirected to login on next visit. |
| Dependencies | User must exist in the system (CH-1 must be done first) |
| Child Tasks | CH-2.1, CH-2.2, CH-2.3, CH-2.4, CH-2.5 |
That acceptance criteria is directly copied from the FRD entry we wrote in Post 2. Claude did not invent it — it extracted and reformatted it. That is the point. You write things once, in the FRD, and everything downstream — tickets, test cases, Confluence pages — comes from the same source.
Three Reusable Prompt Templates
Copy these and adapt the feature name and context for any project. The structure stays the same every time.
TEMPLATE A: EPIC GENERATION
----------------------------------------
Read [path to FRD].
Identify all Epics from the [feature area] section.
For each Epic output: name, description (2 sentences),
FRD sections covered, point estimate (Fibonacci), dependencies.TEMPLATE B: STORY GENERATION
----------------------------------------
For the "[Epic name]" Epic, generate all Stories.
Each Story: user story format, 3-6 acceptance criteria,
point estimate, dependencies on other Stories.
One sprint max per Story. Do not generate Tasks yet.TEMPLATE C: TASK GENERATION
----------------------------------------
For Story [ID] ("[Story name]"), generate development Tasks.
Each Task: concrete technical work, 1-2 days for one developer,
specific title, dependencies within this Story.
Cover: API, frontend, business logic, and tests.Pushing Tickets to Jira via the MCP
Once the tickets are generated and reviewed, you can push them directly to Jira without touching the Jira interface. The Atlassian MCP handles the API calls.
PROMPT 5 - Create Jira Ticket via MCP
Using the Atlassian MCP, create the following Jira issue:
Project: CLIENTHUB
Issue type: Story
Summary: User Login
Description: As any registered user, I want to log in with my email
and password so I can access my account and projects.
Acceptance criteria: [paste the 6 criteria from CH-2]
Story points: 5
Epic link: Authentication and Role System
Labels: auth, phase-1
After creating it, return the issue key and URL.Run this once per Story. For tasks, use the same prompt with issue type “Task” and link them to the parent Story. The whole Authentication Epic — one Epic, four Stories, five Tasks — took about eight minutes to push.
When Claude Surfaces Ambiguity — Pay Attention
Sometimes, mid-generation, Claude will stop and flag something rather than making something up. This happened on ClientHub:
“The FRD mentions that clients can only view deliverables for projects they are invited to, but there is no spec for how that invitation works. Should I create a Story for the invitation flow, or is this handled outside the system (e.g. manually by the PM)?”
That is not a failure. That is Claude doing its job properly. The FRD had a gap — a business rule that referenced an invitation mechanic that was never specced. If Claude had silently generated a ticket for it, the developer would have built something without a spec. Instead, we caught it, went back to the FRD, and added an invitation flow spec before any ticket was created.
How to handle it:
- If it should be built: say so, give Claude the missing context, then ask it to continue generating.
- If it is out of scope: tell Claude to skip it and note “handled outside the system” in the relevant ticket description.
- If you are unsure: stop, update the FRD first, then resume ticket generation from the updated document.
What Is Next
Epics, stories, and tasks are in Jira. The next thing QA needs is test cases — structured, feature-by-feature, covering happy paths, edge cases, and role-based scenarios. Writing test cases from memory is slow and incomplete. Writing them from the FRD with Claude takes a fraction of the time and catches things a manual pass would miss.
Post 7 shows exactly how to do it, using the Deliverable Approval Workflow as the worked example.
Next in this series: Post 7 — Write Complete Test Cases from Your Functional Docs Using Claude
Got questions? Drop them in the comments — I read every one.