Introducing the Jira integration: connect change requests to delivery tracking
Send change requests from Kairo to Jira, keep the product context in Kairo, and let teams that use Jira track delivery without duplicating work.
Most product teams don’t get to choose one tool overnight. Product definition may move forward in Kairo, but engineering execution often still runs through Jira: the boards, workflows, reporting, rituals, and stakeholder habits are already there.
The Jira integration is built for that reality. Kairo remains the source of truth for what should be built and why. Jira stays available for the teams that need it to track delivery.
Send a change request to Jira
From any change request, a member picks the document to send from, for example the product definition, and Kairo creates a Jira issue: a clear summary, a description generated from the change request’s context, the acceptance criteria where available, and a link back to the change request in Kairo.
The Jira issue is not a disconnected copy. It points back to the product definition, the technical plan, the documents, and the discussion in Kairo, so anyone landing in Jira finds the full context in one click.
Set it up once per Jira project
Jira is connected once, through OAuth. A mapping then tells Kairo where change requests go: the Jira site and project, the issue types members may pick, and the issue type each kind of change request uses, whether it’s a feature, an improvement, a fix, or technical work. Your team’s Jira configuration stays exactly as it is.
Keep the plan in Kairo, track the work in Jira
Kairo is where a change request is defined, discussed, and planned. Jira is where many teams still coordinate execution. The integration supports that split deliberately.
When a change request has a technical plan, Kairo can also create the plan’s tasks as child issues in Jira, if the mapping allows it. When the plan changes, syncing the tasks again brings Jira up to date, so the execution tracker follows the work breakdown without Jira becoming the place where the product thinking happens.
If a task is removed from the technical plan, Kairo keeps that relationship visible instead of silently losing track of it.
See Jira status from Kairo
Once a change request has been sent, its linked Jira issues stay visible on it in Kairo, each with its Jira key, summary, link, and last known status.
Product and engineering get a shared view: the product context stays in Kairo, and Jira’s delivery status is visible enough that nobody has to jump between tools just to understand progress.
When the main Jira issue reaches Done, Kairo can reflect that completion on the change request, while the change request remains the source of truth for the requirement itself.
Built for teams that move gradually
Some teams will eventually run their whole product workflow in Kairo. Others will keep Jira for delivery because the organization already depends on it. Both paths are valid.
The Jira integration lets teams adopt Kairo without forcing a process migration on day one. Product managers define better change requests in Kairo, engineers still receive trackable work in Jira, and stakeholders follow progress in the tools they already know.