Découvrez l'intégration Jira : des change requests reliées au suivi de livraison
Envoyez vos change requests de Kairo vers Jira, gardez le contexte produit dans Kairo, et laissez les équipes sur Jira suivre la livraison sans doublon.
La plupart des équipes produit ne changent pas d’outil du jour au lendemain. La définition produit peut avancer dans Kairo, mais l’exécution côté engineering passe souvent encore par Jira : les tableaux, les workflows, le reporting, les rituels et les habitudes des parties prenantes y sont déjà.
L’intégration Jira est conçue pour cette réalité. Kairo reste la source de vérité sur ce qu’il faut construire et pourquoi. Jira reste disponible pour les équipes qui en ont besoin pour suivre la livraison.
Envoyer une change request vers Jira
Depuis n’importe quelle change request, un membre choisit le document à partir duquel envoyer, par exemple la définition produit, et Kairo crée une issue Jira : un résumé clair, une description générée à partir du contexte de la change request, les critères d’acceptation quand ils existent, et un lien vers la change request dans Kairo.
L’issue Jira n’est pas une copie déconnectée. Elle renvoie à la définition produit, au plan technique, aux documents et aux échanges dans Kairo : quiconque arrive dans Jira retrouve tout le contexte en un clic.
Une configuration par projet Jira
Jira se connecte une seule fois, via OAuth. Un mapping indique ensuite à Kairo où envoyer les change requests : le site et le projet Jira, les types d’issue que les membres peuvent choisir, et le type d’issue utilisé pour chaque type de change request, qu’il s’agisse d’une fonctionnalité, d’une amélioration, d’un correctif ou d’un travail technique. La configuration Jira de votre équipe reste exactement la même.
Le plan dans Kairo, le suivi dans Jira
Kairo est l’endroit où une change request est définie, discutée et planifiée. Jira est l’endroit où beaucoup d’équipes coordonnent encore l’exécution. L’intégration assume ce partage.
Quand une change request a un plan technique, Kairo peut aussi créer les tâches du plan comme issues enfants dans Jira, si le mapping l’autorise. Quand le plan évolue, une nouvelle synchronisation des tâches met Jira à jour : l’outil de suivi épouse le découpage du travail, sans que Jira devienne l’endroit où se fait la réflexion produit.
Si une tâche est retirée du plan technique, Kairo garde ce lien visible au lieu de le perdre en silence.
Voir le statut Jira depuis Kairo
Une fois la change request envoyée, ses issues Jira liées restent visibles dans Kairo, chacune avec sa clé Jira, son résumé, son lien et son dernier statut connu.
Produit et engineering partagent la même vue : le contexte produit reste dans Kairo, et le statut de livraison dans Jira est assez visible pour que personne n’ait à jongler entre les outils pour comprendre où en est le travail.
Quand l’issue Jira principale passe à Done, Kairo peut refléter cet achèvement sur la change request, qui reste la source de vérité pour le requirement lui-même.
Conçu pour les équipes qui avancent progressivement
Certaines équipes finiront par faire tourner tout leur workflow produit dans Kairo. D’autres garderont Jira pour la livraison, parce que l’organisation en dépend déjà. Les deux chemins se valent.
L’intégration Jira permet d’adopter Kairo sans imposer une migration de process dès le premier jour. Les product managers définissent de meilleures change requests dans Kairo, les ingénieurs reçoivent toujours un travail suivi dans Jira, et les parties prenantes suivent l’avancement dans les outils qu’elles connaissent déjà.