Atlassian Requirements to Jira Partner

Your agent for transforming requirements documents, meeting notes, and specifications into structured Jira issues — with proper story formatting, acceptance criteria, and ticket hierarchy.

When to Use This Agent

Choose Atlassian Requirements to Jira Partner when:

• Converting product requirements documents (PRDs) into Jira epics, stories, and tasks
• Structuring user stories with acceptance criteria from meeting notes or specs
• Creating well-organized Jira ticket hierarchies from unstructured requirements
• Generating sprint-ready tickets with estimates and dependencies
• Translating business requirements into technical implementation tickets

Consider alternatives when:

• You need project management strategy — use a planning agent
• You need technical architecture decisions — use an architect agent
• You need actual Jira API integration — use a Jira automation tool

Quick Start

Copy
# .claude/agents/requirements-to-jira.yml
name: Atlassian Requirements to Jira Partner
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Requirements analysis agent that transforms specifications into structured Jira issues with proper hierarchy

Example invocation:

claude "Read our PRD at docs/user-auth-prd.md and create a set of Jira tickets — organize as an epic with user stories, include acceptance criteria, and estimate story points"

Core Concepts

Ticket Hierarchy

Level	Jira Type	Purpose	Example
Initiative	Initiative	Strategic goal	"Improve user retention"
Epic	Epic	Large feature	"User authentication system"
Story	Story	User-facing capability	"As a user, I can reset my password"
Task	Task	Technical work	"Set up OAuth2 provider config"
Sub-task	Sub-task	Granular implementation step	"Write password reset email template"

User Story Format

Copy
## Title: [Action-oriented, user-perspective title]

**As a** [user role]
**I want to** [action/capability]
**So that** [business value/outcome]

### Acceptance Criteria
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] Edge case: [scenario] is handled with [behavior]

### Technical Notes
- Implementation approach: [brief technical guidance]
- Dependencies: [other tickets this depends on]
- API changes: [any contract changes needed]

### Estimation
- Story Points: [1/2/3/5/8/13]
- Risk: [Low/Medium/High]

Configuration

Parameter	Description	Default
ticket_format	Output format (jira-markdown, csv, json)	jira-markdown
estimation_method	Estimation approach (story-points, t-shirt, hours)	story-points
include_acceptance	Generate acceptance criteria	true
include_technical	Include technical implementation notes	true
hierarchy_depth	Ticket depth (epic-story, epic-story-task, full)	epic-story-task

Best Practices

1. Start with the user's goals, not the implementation. Extract "what the user needs to accomplish" from the requirements before breaking down into tickets. Stories should describe user value, not technical tasks. "User can log in with SSO" not "Implement SAML2 endpoint."

2. Write acceptance criteria as testable Given/When/Then statements. Vague criteria like "login works correctly" can't be verified. "Given a valid SSO token, when the user clicks Login, then they are redirected to the dashboard within 2 seconds" is testable and unambiguous.

3. Keep stories small enough to complete in one sprint. If a story can't be finished in 2-3 days, it's too large. Split by user workflow steps, data scope, or implementation phases. Large stories create integration risk and make progress hard to measure.

4. Identify and document dependencies between tickets. Mark explicit "blocked by" relationships between tickets that have ordering constraints. This helps sprint planning and prevents developers from starting work that can't be completed yet.

5. Include non-functional requirements as separate stories. Performance targets, security requirements, and accessibility standards often get lost when bundled into functional stories. Create explicit NFR stories: "API response time is under 200ms at p99."

Common Issues

Requirements are too vague to create actionable tickets. When the PRD says "improve search," you need to clarify scope before creating tickets. Document what you know, flag open questions in the tickets, and create a spike story for research before implementation stories.

Story point estimates are wildly inconsistent. Without calibration, "3 points" means different things to different people. Include a reference table: "1 = trivial change, 3 = straightforward feature, 5 = complex feature, 8 = significant work, 13 = needs breakdown."

Generated tickets don't match the team's workflow. Different teams use different Jira workflows, custom fields, and conventions. Customize the output format to match the team's existing ticket template, required fields, and labeling conventions.