"Which Services Does This Epic Touch?" Is a Question ChatGPT and Jira Together Still Can't Answer

"Which services does this epic touch?" is a question product owners and scrum masters ask at the beginning of every sprint planning session that involves significant backend work. It determines risk. It determines which teams need to be in the room. It determines whether this is a two-week sprint or a six-week project. It is one of the most important questions in software planning.

No current combination of AI and Jira can answer it correctly. Not ChatGPT connected to Jira. Not Claude with Atlassian's MCP. Not Jira's own native AI. These tools know the epic's ticket content — the description the author wrote, the services they thought to mention, the scope as it was understood when the ticket was created. They do not know what the codebase actually connects. And those two things are frequently not the same.

The ticket says two services. The codebase traces six. Sprint planning proceeds based on two. Week two of the sprint surfaces four additional dependencies nobody planned for.

Why the question requires two sources simultaneously

"Which services does this epic touch?" is not a Jira question. It is not a codebase question. It is a question that sits at the intersection of both: the intent described in the ticket and the actual dependencies that exist in the system. You need Jira to know what the epic is. You need the codebase to know what it touches.

"Which services does this epic touch?" — what each tool knows:

  Tool                    | Knows Jira epic content | Knows which services it touches
  ------------------------+-----------------------+----------------------------------
  ChatGPT + Jira          | Yes                   | No (only what the ticket says)
  Claude (web) + Jira     | Yes                   | No (only what the ticket says)
  Cursor / Claude Code    | No                    | Yes (reads the codebase)
  Jira alone              | Yes                   | No
  Codebase alone          | No                    | Yes (but doesn't know the ticket)
  Jira + codebase context | Yes                   | Yes

ChatGPT connected to Jira can tell you what the ticket says the epic touches. That is a different answer from what the epic actually touches. Cursor or Claude Code can trace the codebase and identify service dependencies — but without knowing which epic you are asking about, they are answering a generic architecture question rather than a planning question. Neither alone closes the gap. The question requires both sources at the same time, interpreted together.

Why ticket descriptions undercount service dependencies

Epic tickets describe intent from the moment they are written, by someone whose primary job is not system architecture. The author knows which services they expect to touch. They do not know which services will be implicitly affected by those changes — because implicit dependencies are not visible without reading the codebase. The ticket documents the expected blast radius. The codebase contains the actual one.

The gap between ticket description and system reality:

  Epic ticket description:
    "Refactor the checkout flow to support multi-currency pricing"
    Services mentioned: payment-service, pricing-service

  What the codebase actually shows:
    Direct dependencies: payment-service, pricing-service, currency-conversion-service
    Indirect dependencies: user-service (fetches billing country),
                          notification-service (sends payment confirmation emails),
                          audit-service (logs all pricing changes for compliance)
    Shared schema: 3 services read from the orders table
    Risk: notification-service email templates reference price fields
          that will be formatted differently post-refactor

  What the ticket named: 2 services
  What the codebase connects: 6 services (3 direct, 3 indirect)
  What gets scheduled for risk review in sprint planning: 2 services

This pattern — two explicitly named services, six actually connected — is not unusual. It is the norm for any meaningful change to a service-oriented system. The named services are the ones the ticket author thought about. The additional services are the ones connected through shared schemas, event subscriptions, or implicit dependencies that are only visible by tracing the codebase. Sprint planning that is based on the two-service answer and not the six-service reality is planning that will fail in week two.

The sprint planning consequence

Sprint planning sessions where "which services does this epic touch?" is answered from ticket content rather than codebase analysis produce plans with incomplete risk assessments. Risk review is conducted for the services the ticket named. Mitigation is planned for those dependencies. The additional services that the codebase reveals — and that the ticket did not mention — arrive as surprises mid-sprint.

These surprises are not unpredictable. Multi-team dependency blindness is a structural problem in sprint planning that emerges consistently from the gap between ticket intent and codebase reality. The teams that own the unplanned-for services are not in the sprint planning meeting because nobody knew they were affected. They are pulled in mid-sprint to address dependencies that were always there — just not visible from the Jira side of the information.

The version of the question that also needs to work

"Which services does this epic touch?" is the planning version of the question. Sprint planning also needs: "Are there open bugs in the same area as the work we are planning this sprint?" "Which epics on the roadmap will interact with the services this sprint's work touches?" "If we change the data model in this ticket, what else reads from that model?"

These are all the same category of question: what is in Jira, applied to what is in the codebase, interpreted together. None of them are answerable from Jira alone. None of them are answerable from the codebase alone. Each requires both sources, queried simultaneously, with the answer surfaced in plain language for the product owner or scrum master asking it.

What the right integration enables

When Jira and the codebase are connected in a shared context layer, the questions change in character. They stop being requests for engineering to interpret system behavior and start being self-serve answers that product and process roles can get before the sprint planning meeting starts.

Kognita's Jira integration enables cross-source answers:

  "Which Jira epics touch the payment service?"
    → combines: Jira epic scope + codebase service map
    → answer: EPIC-44, EPIC-67, EPIC-89 — and here is how each touches it

  "Are there open bugs in the same area as what we're planning this sprint?"
    → combines: open bug tickets + sprint scope + codebase overlap
    → answer: BUG-23 and BUG-31 are in the checkout flow — same area as EPIC-112

  "What is the actual blast radius of this epic?"
    → combines: epic ticket + codebase dependency graph
    → answer: 6 services directly or indirectly affected, here are the paths

The product owner who can ask "which Jira epics touch the payment service?" before the planning meeting arrives knowing the answer. The scrum master who can ask "are there open bugs in the same area as this sprint's work?" can build risk mitigation into the plan rather than discovering the conflict in week two. These are not advanced analytical capabilities. They are basic planning questions that currently require either engineering involvement or guesswork from ticket content.

Why Jira's native AI doesn't solve this

Atlassian's AI features — Rovo and its embedded assistants — work within the Jira data model. They can identify patterns in ticket history, suggest assignments, summarize epics, and flag staleness. They are genuinely useful for ticket management. They still need codebase ground truth for any question that is about system behavior rather than ticket content.

"Which services does this epic touch?" is a system behavior question. Jira's AI can tell you what the epic's tickets say about which services are in scope. The codebase tells you what is actually connected. Until Jira's AI is connected to a live codebase index — which it is not, by design, because Jira is a work management system not a code intelligence system — it will continue to answer this question from ticket descriptions rather than system reality.

Final take

"Which services does this epic touch?" is the sprint planning question that neither Jira nor any AI connected only to Jira can answer accurately. The answer lives at the intersection of ticket intent and codebase reality. The teams that get this wrong in planning discover the correct answer mid-sprint, when it costs twice as much to address.

Getting sprint planning right requires both sources simultaneously: what the epic says it will do, and what the codebase reveals about what it will actually affect. Any planning process that can only access one of those sources is planning half-blind — and the half it cannot see is the half that determines whether the sprint holds.