Top 15 des requêtes Jira JQL qu’un Product Owner doit maîtriser

Voici les requêtes Jira JQL qu’un Product Owner doit maîtriser. Parce qu’être Product Owner, ce n’est pas “attendre la revue”. C’est observer, anticiper, arbitrer, parfois dire non, souvent clarifier, et surtout éviter les mauvaises surprises en fin de sprint.

Pas de temps de lire l’article, écoutez-le !

Jira, bien utilisé, peut être un vrai allié… à condition de ne pas se limiter au board Scrum.
Les requêtes JQL permettent au PO de voir ce que le board ne montre pas toujours : les signaux faibles, les risques, les dérives.

Top 10 des requêtes Jira JQL qu’un Product Owner doit maîtriser

Voici une liste de requêtes Jira JQL concrètes, utilisables au quotidien pendant un sprint, organisées selon les moments clés du sprint.

Requêtes Jira JQL du Product Owner – Début de sprint : sécuriser l’engagement

Récits engagés dans le sprint

Une requête plutôt basique pour commencer cet article, mais j’ai été surprise de voir des PO filtrer sur l’identifiant du sprint puis ajuster leurs requêtes à chaque changement d’itération alors qu’il existe une façon simple de filtrer de façon dynamique sur :

Le sprint en cours : openSprints()
Les sprints futurs : futureSprints()
Les sprints passés : closedSprints()

sprint in openSprints()

👉 Vue de référence : ce qui est réellement engagé.

Récits sans estimation

Même si ce n’est pas au PO qu’incombe la responsabilité d’analyser et présenter en affinage l’ensemble des tickets, c’est bien lui qui est imputable de s’assurer que les tickets seront prêts avant le démarrage du sprint.

issuetype = Story AND sprint in openSprints() AND "Story Points" is EMPTY

👉 Signal immédiat d’un sprint mal préparé ou d’un refinement incomplet.

Récits sans Epic

Dans ma carrière, j’ai souvent vu des tickets sans parents et personne ne semblait être dérangé par cette pratique. Personnellement, je pense que ce manque de rigueur dans la gestion du backlog se paiera forcément un jour… notamment quand l’organisation commence à challenger la valeur réellement livrée par une équipe et que l’on ne sait plus trop pourquoi la demande a été réalisée.

issuetype = Story AND sprint in openSprints() AND "Epic Link" is EMPTY

👉 Perte de cohérence produit : difficile de défendre la valeur sans rattachement stratégique.

Bugs embarqués dans le sprint

Pour assurer un haut niveau de qualité produit, je fais partie des PO qui aiment embarquer un minimum de corrections à chaque sprint. Évidemment, chaque bug engagé est avant tout discuté avec les clients pour se concentrer sur des corrections de valeur. Ce n’est pas une porte ouverte au gold plating !

issuetype = Bug AND sprint in openSprints()

👉 Engagez-vous aussi à améliorer la qualité produit en collaborant avec vos parties prenantes.

Requêtes Jira JQL du Product Owner – Pendant le sprint : pilotage quotidien

Tickets bloqués

Une bonne pratique pour un PO est de faire un suivi régulier sur les travaux qui sont bloqués dans le sprint en cours afin de trouver rapidement une solution avec l’aide de l’équipe.

status = Blocked AND sprint in openSprints()

👉 Là où le PO peut (et doit) agir rapidement : arbitrage, clarification, décision.

Tickets non mis à jour depuis plusieurs jours

Une autre bonne pratique en tant que PO est de suivre les tickets qui ne changent pas de statut durant plusieurs jours. Une bonne façon d’identifier des bloquants non nommés et des tickets qui tombent entre deux chaises.

updated <= -3d AND sprint in openSprints() AND status != Done

👉 Excellent révélateur de faux “In Progress” ou de sujets évités.

Récits jamais démarrés

Encore une bonne pratique pour éviter les mauvaises surprises en fin de sprint, faire un suivi régulier sur les tickets qui ne sont pas débutés.

status = "To Do" AND sprint in openSprints()

👉 Plus le sprint avance, plus ce filtre devient critique.

Récits en revue / validation

Il est possible que durant le sprint, un ticket soit en attente de test par vos clients. C’est en général les tickets qui tombent dans l’oubli durant le sprint et qui vont stresser tout le monde 2 jours avant la fin du sprint quand on prend conscience que personne n’a pris en charge la relance des tests utilisateurs.

status = "Test TA" AND sprint in openSprints()

👉 Soyez proactif, n’attendez pas la fin du sprint pour relancer vos clients.

Bugs critiques ouverts

Et non, chers PO, ce n’est pas parce que le sprint a démarré que l’on ne peut rien y ajouter. C’est un point récurrent de tension avec les clients. N’oubliez pas durant tout le sprint de faire un bon suivi sur les bug qui sont créés en cours de sprint et de les prioriser de façon régulière avec les parties prenantes. Il se peut qu’un nouveau bug soit plus urgent qu’un bug déjà engagé, alors adaptez-vous et négociez de sortir un bug pour un autre !

issuetype = Bug AND priority in (Highest, High)

👉 Arbitrage immédiat entre valeur, qualité et engagement de sprint.

Requêtes Jira JQL du Product Owner – Signaux faibles à surveiller absolument

Récits ajoutés en cours de sprint

Le PO n’est pas responsable de créer tous les tickets dans le backlog, parce contre les membres de l’équipe devrait toujours aviser le PO quand un nouveau ticket est ajouté en cours de sprint. Mais l’erreur est humaine, soyez indulgent et identifiez rapidement les changements de périmètre.

created >= startOfSprint() AND sprint in openSprints()

👉 Identifier les changements de périmètre.

Récits retirés du sprint

Là encore, l’erreur est humaine et il arrive qu’un ticket soit retiré d’un sprint par un membre de l’équipe sans vous avoir avisé au préalable. Parlez avec l’équipe et identifiez rapidement les changements de périmètre.

sprint was in openSprints() AND sprint not in openSprints()

👉 Données précieuses pour la rétrospective PO / équipe.

Récits reportés depuis un sprint précédent

Dans ma carrière, je vois beaucoup de PO reporter d’un sprint à l’autres leurs engagements sans se poser plus de questionner. C’est une erreur ! Si un ticket est reporté depuis plusieurs sprints, cherchez la cause profonde à ce problème. Sur-engagement, dépendance existante, récit mal découpé ou mal compris ? Cherchez, il y a forcément une explication qui mérite d’être explorée lors de la prochaine rétrospective.

sprint in closedSprints() AND sprint in openSprints()

👉 Indicateur classique de sur-engagement ou de stories mal découpées.

Récits avec dépendances non résolues

Il est tout à fait acceptable de débuter un sprint avec des dépendances. Le risque est plus élevé, mais cela ne doit pas être un frein à l’engagement. Par contre, mesurez bien le risque et arrimez-vous au plus tôt pour que la dépendance soit levée au plus tôt durant le sprint.

issue in linkedIssues() AND sprint in openSprints() AND status != Done

👉 Les dépendances ignorées deviennent souvent des retards “inexpliqués”.

Requêtes Jira JQL du Product Owner – Fin de sprint : préparer revue et rétrospective

Récits terminés

Une bonne base pour savoir ce qui est terminé et démontrable durant la prochaine revue de sprint.

status = Done AND sprint in openSprints()

👉 Base factuelle pour la revue de sprint.

Récits non terminés

La bête noire de tous les PO: les tickets non terminés. Et pourtant ce n’est pas une catastrophe si vous savez expliquer la situation et que vous vous engagez en équipe à creuser ce qui s’est passé pour éviter de reproduire la même erreur. Mais préparez-vous à avoir des questions de la part des parties prenantes durant la revue. Soyez honnête, transparent et faite preuve d’introspection. Faire une erreur une fois c’est humain, faire plusieurs fois la même erreur, c’est être idiot !

status != Done AND sprint in openSprints()

👉 Décisions à prendre : report, découpage, abandon, requalification.

Conclusion – Top 15 des requêtes Jira JQL du Product Owner

Un bon Product Owner ne pilote pas à l’instinct ni uniquement via le board. Ces requêtes JQL ne servent pas à “faire du reporting”, mais à voir plus clair, anticiper et prendre de meilleures décisions pendant le sprint, quand il est encore temps d’agir.