Turn the notes below into one implementation-ready Jira issue. Do not assume missing product, technical, security, or timeline decisions. Request or problem: [REQUEST] User and business context: [CONTEXT] Known requirements and non-goals: [REQUIREMENTS AND NON-GOALS] Technical context and dependencies: [TECHNICAL CONTEXT] People, teams, and proposed owner: [OWNERS AND STAKEHOLDERS] Target milestone or date: [TIMELINE]
Produce the issue in this exact order: Title: a verb-led title under 90 characters. Problem and outcome: two to four sentences explaining who is affected and what changes. Scope: numbered in-scope items and explicit non-goals. Implementation plan: ordered steps, each with a responsible role or named owner where known; mark unknown ownership as “TBD.” Acceptance criteria: five to eight testable Given/When/Then statements that cover the main path, a failure or empty-state path, permissions or security where relevant, and analytics or logging where relevant. Dependencies and risks: blockers, approvals, systems, and decisions needed before release. Timeline: proposed checkpoints with dates only where I supplied dates. Do not turn a hoped-for result into a committed date, estimate, or named owner. Do not write vague criteria such as “works correctly” or “is user-friendly.” Distinguish product requirements from implementation suggestions. Before answering, check that each acceptance criterion can be verified and that no listed dependency is disguised as completed work. Ask up to three clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [REQUEST] | Describe the change, bug, feature, or operational work request. | Add an account-level setting that lets workspace admins require SSO for all members. |
| [CONTEXT] | Explain the affected users, business reason, and current behavior. | Enterprise customers currently ask support to enforce SSO manually; admins need a self-service control before annual security reviews. |
| [REQUIREMENTS AND NON-GOALS] | List decisions already made and work explicitly outside the issue. | In scope: admin toggle, confirmation screen, member sign-in behavior, audit event. Non-goals: new identity providers, SCIM provisioning, changing existing SSO setup. |
| [TECHNICAL CONTEXT] | Provide relevant systems, APIs, environments, constraints, and known dependencies. | React settings app; Node API; existing SAML and OIDC login flows; account settings service; audit-event pipeline; feature flag required for rollout. |
| [OWNERS AND STAKEHOLDERS] | Name the responsible people or teams and anyone who must review or approve. | Proposed owner: Maya Chen, product engineer. Reviewers: Identity team, Security, Support operations. Product manager: Luis Romero. |
| [TIMELINE] | Provide the release target, milestones, or date constraints if they exist. | Design review by October 10; engineering complete by October 31; staged rollout begins November 5. |
How to use
- Put only decisions already made in the requirements field and label wishes or open questions as such.
- Give the AI the actual system names and rollout constraints so dependencies are visible rather than implied.
- Read each acceptance criterion as a test case; replace any outcome that cannot be observed or measured.
- Send this follow-up: “Split this into the smallest independently releasable Jira issues, preserving dependencies and avoiding duplicate acceptance criteria.”
Variations
Bug report
Use this when a defect needs reproducible evidence and a safe fix path.
Write a Jira bug report from these details: [OBSERVED BEHAVIOR], [EXPECTED BEHAVIOR], [REPRODUCTION STEPS], [ENVIRONMENT], [IMPACT], and [LOGS OR SCREENSHOTS]. Include title, severity rationale, numbered reproduction steps, actual versus expected result, suspected component only if supported, and acceptance criteria for the fix plus regression coverage. Do not invent a root cause or severity. Flag missing reproduction evidence. Check that another engineer could reproduce the issue using the provided steps. Ask up to three questions only if required inputs are missing.
Epic breakdown
Use this when a larger initiative needs a deliverable-oriented plan before tickets are created.
Break this initiative into a Jira epic and child issues: [INITIATIVE], [USER OUTCOME], [SYSTEMS AND DEPENDENCIES], [TEAM CAPACITY], and [TARGET MILESTONE]. Produce an epic summary, success measures, non-goals, and a table of child issues with deliverable, primary owner role, dependency, and release sequence. Each child issue must be independently testable and small enough to estimate. Do not assign dates or people not supplied. Check that no child issue is merely a vague phase label. Ask up to three questions only if required inputs are missing.
Release checklist
Use this when an approved change is approaching production rollout.
Create a Jira release checklist for [CHANGE] in [ENVIRONMENT AND RELEASE METHOD]. Use these dependencies and approvals: [DEPENDENCIES], and this rollback information: [ROLLBACK PLAN]. Include pre-release validation, communications, monitoring signals, go/no-go owner, rollout steps, rollback triggers, and post-release verification. Keep unknown items marked TBD; do not claim a test, approval, or backup exists unless stated. Check that every rollback trigger has an observable signal and a responsible decision-maker. Ask up to three questions only if required inputs are missing.
Tips
- Write non-goals as clearly as scope items; they prevent a ticket from quietly absorbing adjacent work during implementation.
- Acceptance criteria should describe observable behavior, including what happens when permissions fail, data is absent, or an upstream service is unavailable.
- A named owner can own delivery, but approvals and dependencies need their own labels so a ticket does not appear ready when it is blocked.
- Do not use a due date as an estimate; record the date constraint and let the delivery team provide an estimate separately.
FAQ
How detailed should a Jira ticket be?
It should be detailed enough for someone outside the original conversation to understand the outcome, scope, constraints, and how success will be tested. It does not need to prescribe every implementation choice.
Should every Jira issue have acceptance criteria?
Most product and engineering work benefits from them because they define done. For research or discovery work, use clear questions, deliverables, and a decision point instead.
Can AI estimate Jira work?
AI can identify dependencies and unknowns, but estimates require the team’s knowledge of the codebase, capacity, and risk.