The anatomy of a Jira ticket for AI product management in agentic engineering

Why your Jira ticket is a prompt in 2026

Atlassian says it itself: in the new Jira world every work item is a dataset AND a prompt for agents. Summary, description and linked documents flow straight into a coding agent's start prompt. A vague ticket costs extra tokens and rework; a context-rich ticket lets the agent start informed. That changes the demand on product managers fundamentally: you no longer write only for the dev next door, but for a machine that takes everything literally.¹

In 2025, “context engineering” established itself as the successor to “prompt engineering”. Anthropic puts it plainly: “good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.” The reason is a phenomenon called context rot: the more tokens are in the context window, the worse the model gets at retrieving precise information from it. More context is not better – the right context at the right time is.²

For product management that means: a ticket that throws everything into a giant description field is just as bad as an empty one. The perfect ticket is curated. It holds exactly the architecture decisions, acceptance criteria and constraints relevant to this one story, and links the rest instead of copying it in. The bottleneck isn't the coding – it's everything before it.

What stays: the proven anatomy as the foundation

Before we add AI, the foundation. A Jira story classically consists of issue type and hierarchy (epic, story, task, bug, sub-task), the core fields (summary, description, acceptance criteria, priority, labels, components, epic link) and the user-story format “As a [role] I want [goal] so that [benefit]”. Important: “as a user” is lazy. Be specific, e.g. “As a marketing manager ahead of a campaign launch”. Sharpening the role hands both human and agent the first slice of context for free.

On top sit the quality heuristics. The INVEST criteria (independent, negotiable, valuable, estimable, small, testable) check whether a story is sprint-ready. The three C's (card, conversation, confirmation) are a reminder that the ticket is only the anchor, the conversation clarifies the detail, and the acceptance criteria are the confirmation. Two patterns dominate the criteria: Given/When/Then for context-dependent behaviour and the rule-based checklist for lists of conditions. Rule of thumb from practice: more than ten acceptance criteria is a signal to split the story.³

Two gates frame the work. The definition of done is part of Scrum and applies to all backlog items: code reviewed, tests green, docs current, PO approval. The definition of ready is NOT part of the Scrum Guide but an optional tool describing when a story may enter a sprint: clear description, testable acceptance criteria, estimated, no unresolved blockers. Jeff Sutherland argues a strong definition of ready can double velocity – while warning that an overly rigid one leads to perpetual planning. None of this is obsolete. In the agentic era it becomes more important, because it delivers exactly the structure and testability agents need.⁴

How BMAD turns 100 words into a context-complete ticket

A classic Jira ticket has around 100 words; the rest of the context lives in human memory and scattered documents. The BMAD-METHOD (Breakthrough Method for Agile AI-Driven Development) flips that. Its heart is the story file: a structured Markdown document of 500 to 1,000 words that embeds everything a dev or AI agent needs. Instead of treating an LLM as a generalist, BMAD assigns specialised agent roles (analyst, PM, architect, PO, scrum master, dev, QA) mirroring a real team – each with tightly bounded context.⁵

The canonical section structure of a story file is tellingly concrete: status, story (“as a / I want / so that”), acceptance criteria, tasks/subtasks (with “(AC: #N)” notation tying each task to a numbered criterion), dev notes (architecture context plus source citations in the format [Source: docs/architecture.md#section]), testing, dev agent record, change log and QA results. Those source citations are the trick: the context isn't gone, it's traceably linked.⁵

The division of roles is decisive. On creation, the scrum-master agent fills status, story, acceptance criteria, tasks, dev notes and testing – with the brief to prepare “a comprehensive, self-contained, and actionable story file”. The dev agent is explicitly authorised ONLY to edit certain sections (task checkboxes, dev agent record, change log, status); it may not alter story, acceptance criteria or dev notes. The QA agent fills the QA results at the end. That is built-in governance: who may add what, and when, is defined – exactly what counts in an audit.⁵

Notably, BMAD drops story points. Instead of “how many points?” it asks “is the story small enough for an agent to finish in one session?” – the target is 2 to 8 hours, about a developer-day, otherwise it gets split. On large projects the PRD is sharded so dev agents load only the information relevant to one task instead of a 100-page document. That is the same philosophy GitHub captures with Spec Kit: the spec is the source of truth, the code is the derivative – “intent is the source of truth”.^5,6

Where the context actually lives: GitHub, meetings, Slack, MCP

The core problem isn't writing the ticket but that relevant knowledge is scattered across five-plus systems. The GitHub integration shows the mechanism: write the issue key (e.g. PROJ-123) into a branch name, commit message or PR title and Jira links it automatically, with the development panel showing every branch, commit and PR with its status. Smart commits extend this with comments, time logging and workflow transitions straight from the commit message. The limitation: this link is mostly one-directional – GitHub activity flows into Jira, but the Jira context doesn't flow back automatically.¹

The second source is meetings. Tools like Granola, Otter, Fireflies or Fathom transcribe and can push action items into Jira. The modern flow: a standup or discovery session is recorded, the AI extracts verifiable action items (with owner, task, deadline), and these are created as clean tickets – ideally with a human-in-the-loop review before creation. Atlassian goes further: in the Spring 2026 release you capture a bug via a Loom recording, and Rovo automatically creates dev-ready work items including reproduction steps and console logs.¹

The connective tissue is MCP. The Model Context Protocol established itself in 2025 as the open standard for how LLMs interact with tools – the adapter that connects an agent to Jira, GitHub, Slack and the rest without hard-coding every integration. Atlassian built a remote MCP server with Anthropic as its first partner, so you open a work item via deep link in Claude Code, Cursor or Copilot with one click – with a pre-filled, context-rich prompt. That way the context doesn't have to be copied into the ticket; the agent loads it just in time.^8,1

The four phases: what gets added to the ticket, and when

Now the synthesis. Here's how a ticket builds up progressively across the Teklens lifecycle – four phases plus a fast lane. This is the column-by-column view for a Kanban board: the ticket starts as a 100-word pointer and ends as a context-complete record of what actually happened.

Phase 01 discover (context workspace). The ticket is born as a signal. Here context from the scattered sources gets connected (Jira, Confluence, code, mail, transcripts). What enters the ticket: a first problem statement, the source signals (customer quote, support ticket, meeting insight), a rough role and a suspected benefit. In Marty Cagan's spirit, a mini opportunity assessment: which problem do we solve, for whom, how do we measure success. Status: idea/draft.¹³

Phase 02 define (the gate). Prioritisation by value, effort, risk – then the ticket is brought into focus: the full user-story format, INVEST-checked, testable acceptance criteria (Given/When/Then), epic link, embedded architecture decisions and constraints, source citations to PRD and architecture, links to Confluence. By the end of this phase the ticket meets the definition of ready. This is the moment a 100-word pointer becomes a context-complete, agent-ready story file.

Phase 03 build (live view). Real-time progress with code context. What gets added now: linked branches, commits and PRs in the development panel (via issue key or deep link), checked-off tasks, the dev agent record (which model, which files changed, completion notes), smart-commit updates. The ticket becomes a living record of what actually happens in the code – not of what was planned weeks ago.

Phase 04 operate (auto-resolve). Solving support and bugs with code context. What gets added now: QA results, linked deployments, incoming bug reports (e.g. auto-created via Loom with repro steps and console logs), the link back to the original story. Here the loop closes: resolved tickets become training material for the “similar work items” feature of future agents, which learn a codebase's conventions from the most similar work items and their PRs.¹

Fast lane. For small or urgent items. Here the ticket only needs a minimal but precise set: a clear problem, one to three acceptance criteria, a code reference. Not every ticket needs the full cascade – but even the fast-lane ticket must be precise, otherwise the agent guesses.

What the data really says about AI productivity

This calls for discipline. The temptation to sell productivity multipliers as results is large – the data isn't. Arguing honestly earns more trust over time than throwing around the 10x promise.

The METR study (arXiv:2507.09089, July 2025) is the hardest evidence: a randomised controlled trial with 16 experienced open-source developers across 246 tasks, primarily with Cursor Pro and Claude 3.5/3.7 Sonnet. Finding: “When developers are allowed to use AI tools, they take 19% longer to complete issues.” Beforehand they expected a 24 per cent speed-up; afterwards they estimated they'd been 20 per cent faster – measured, they were 19 per cent slower. They didn't even notice.⁹

DORA 2025 (“State of AI-assisted Software Development”, nearly 5,000 respondents) frames it: AI adoption at 90 per cent, over 80 per cent report productivity gains. The central finding, verbatim: “AI functions as both mirror and multiplier, reflecting an organization's true capabilities while amplifying their existing strengths and weaknesses.” There's a positive relationship between AI adoption and throughput, but still a negative one with stability. Without strong platforms, clear workflows and fast feedback loops, more volume leads to more instability.¹⁰

GitClear (“AI Copilot Code Quality 2025”, 211m lines of code) shows the flip side: copied lines rose from 8.3 to 12.3 per cent, refactored (“moved”) lines fell from 24.1 to 9.5 per cent. In 2024 copy-paste overtook refactored code for the first time, and blocks with five-plus duplicated lines rose eightfold. That is the direct consequence of speed without context discipline – more output, worse maintainability.¹¹

Faros AI measures, across tens of thousands of developers, 21 per cent more tasks completed and 98 per cent more PRs merged – yet organisational delivery metrics stayed flat, with degraded quality signals (longer review times, more bugs per developer). And Atlassian's own longitudinal observation across 400 engineering organisations finds that even at 90 per cent AI adoption for coding, overall productivity plateaus at a 10 to 15 per cent gain. Individual gains don't automatically scale to the organisation.^12,1

The honest message: AI accelerates, but only in the direction your system already points. Automate bad input and you just ship the mess faster. A precise, context-complete ticket is the lever that decides whether that acceleration turns into value or into technical debt.

The new discipline: the ticket as curated context

Den Delimarsky, principal product manager at GitHub, captures the shift: “We treat coding agents like search engines when we should be treating them more like literal-minded pair programmers. They excel at pattern recognition but still need unambiguous instructions.” That is the new PM discipline: stop dumping context, start curating the right context – for a partner that takes everything literally.⁶

This doesn't replace discovery, it sharpens definition. Discovery stays human, execution becomes the spec – Marty Cagan even says that with generative AI the PM role becomes “more essential and more difficult, not less”. Which framework you choose for execution depends on context: OpenSpec for lean single features with a living spec, BMAD for heavyweight enterprise systems with an audit trail. Both share the same logic as the good ticket: agreement before the code.^13,7,5

And here the ticket pays into the Teklens thesis: the planning software that knows your business. When code, Jira and Confluence become one context an agent understands, the ticket starts informed rather than guessing. Without context an LLM is an intern that guesses; with context it's a team member that thinks along. The context-complete ticket is where that difference is decided.

Frequently asked questions

Recommendations

• Introduce a story template that enforces the anatomy. “As a / I want / so that” lines, a Given/When/Then block, an “out of scope” field and a mandatory epic link. That's the baseline hygiene every AI initiative presupposes.
• Establish a lean definition of ready as a gate. A clear problem, testable acceptance criteria, code and doc references linked, estimated or sliced – before the sprint. The quality gate before the work, not after it.
• Enforce issue keys in branch names and PR titles. That way the development panel fills automatically with branches, commits and PRs. It's the cheapest route to code context on the ticket.
• Pilot meeting-to-ticket with a human in the loop. AI extracts action items from standup and discovery transcripts; a human reviews before creation. Never full autonomy without review – especially not on non-English audio.
• Treat the ticket explicitly as a prompt. Write descriptions a literal-minded pair programmer could implement. Curate context instead of dumping it – and connect sources via MCP instead of copying them in.
• Measure outcomes, not output. If your rework or code-churn rate rises after introducing AI, your tickets are too vague, not your tools too poor. If the share of stories with complete acceptance criteria before sprint start passes 90 per cent, you're ready for more aggressive agent delegation.

Scope & caveats

• The METR study had a small sample (16 developers) in large, mature open-source repos and used early-2025 models (Claude 3.5/3.7). The authors themselves stress the result doesn't generalise universally and that newer models may perform differently. METR revised the design in early 2026 because more and more developers no longer wanted to work without AI.
• BMAD versions differ. The story-file structure and editing rules described here come from the well-documented v4 generation; the current v6 has restructured workflows and section layout, but the underlying principle (self-contained story, role governance, sharding) stays the same. The token target of around 8,000 per story is a third-party characterisation, not an official template figure.
• AI features in Jira move fast. Atlassian's Rovo, “Agents in Jira” and partner integrations are in rapid flux in 2025/2026; availability, plan requirements and scope can change. Atlassian itself notes that the quality and reliability of AI-generated information varies.
• All productivity and quality figures come from external sources (METR, DORA, GitClear, Faros, Atlassian) and are attributed to them – not Teklens results and not promises of specific speed gains. Meeting transcription reaches 95 to 98 per cent accuracy only on clean English audio; with accents and non-English content (relevant for the DACH region) it drops noticeably. Auto-created tickets need human validation.

Sources

Every external figure and quote in this piece – linked so you can verify it.

1. 1.Atlassian, «Agents in Jira» & Rovo (2026) ↗ — Work item as dataset and prompt; deep links, similar work items, Loom-to-ticket.
2. 2.Anthropic, «Effective context engineering for AI agents» (2025) ↗ — Context engineering, finite attention budget, context rot.
3. 3.Bill Wake, «INVEST in Good Stories, and SMART Tasks» (2003) ↗
4. 4.Jeff Sutherland, «Ready: The Dynamic Model of Scrum» (2009) ↗
5. 5.BMAD-METHOD, GitHub-Repository (MIT) ↗ — Self-contained story file, role governance, PRD sharding.
6. 6.GitHub Spec Kit (2025) ↗ — Spec-driven development; “intent is the source of truth”.
7. 7.OpenSpec von Fission-AI ↗
8. 8.Model Context Protocol (Anthropic, 2024) ↗
9. 9.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» (2025), arXiv:2507.09089 ↗ — RCT, 16 developers, 246 tasks: 19 per cent slower with AI.
10. 10.DORA, «State of AI-assisted Software Development» (Google Cloud, 2025) ↗ — Nearly 5,000 respondents; AI as “mirror and multiplier”.
11. 11.GitClear, «AI Copilot Code Quality 2025» (Bill Harding) ↗ — 211m lines of code; duplication multiplied, refactoring fell.
12. 12.Faros AI, «The AI Productivity Paradox» (2025/2026) ↗ — More tasks and PRs per dev, flat org delivery metrics.
13. 13.Marty Cagan / SVPG, «AI Product Management 2 Years In» (2024) ↗

Keep reading in the PM Lab

Related deep dives from the same pillar.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.