Pourquoi un Scrum Master n’a (presque) pas besoin de Jira JQL

Dans de nombreuses organisations, une croyance tenace s’est installée : un bon Scrum Master serait avant tout celui qui sait produire des indicateurs, écrire des requêtes Jira JQL et fournir une visibilité chiffrée sur l’avancement du sprint. Cette attente est souvent présentée comme une évidence, parfois même comme un marqueur de professionnalisme.

Cette vision est pourtant problématique. Elle contribue à réduire le Scrum Master à un rôle de soutien opérationnel, chargé de surveiller et de reporter, au détriment de sa responsabilité première : accompagner les équipes et les organisations vers plus de maturité et d’autonomie. À force de vouloir “objectiver” l’agilité à l’aide d’outils, on finit par en trahir l’esprit.

Pourquoi un Scrum Master n’a (presque) pas besoin de Jira JQL

Soyons clairs : le Scrum Master doit maîtriser Jira et le JQL. Ne pas comprendre l’outil utilisé par l’équipe serait une faiblesse. Mais cette maîtrise n’a de sens que si elle est mise au service de l’apprentissage, de la responsabilisation et de la montée en compétence des rôles, en particulier celui du Product Owner.

Le Scrum Master n’est pas un analyste Jira (ni un secrétaire)

Le rôle du Scrum Master n’est pas de :

❌ surveiller l’avancement des tickets
❌ produire des rapports d’activité
❌ alerter le management à coups de graphiques
❌ compenser les lacunes produit ou organisationnelles

👉 Comme je l’écrivais déjà dans « Ton Scrum Master n’est pas un secrétaire », le Scrum Master n’est pas là pour faire à la place de.

Son rôle est de :

✅ améliorer le système de travail
✅ développer l’autonomie du Product Owner et de l’équipe
✅ rendre visibles les dysfonctionnements
✅ accompagner la montée en maturité agile

Aucune requête JQL, aussi sophistiquée soit-elle, ne remplit ce rôle à elle seule.

Oui, le Scrum Master doit maîtriser Jira JQL (mais pas pour les raisons que l’on croit)

Clarifions un point fondamental !

La maîtrise de Jira n’est pas le problème

Le problème, c’est l’intention derrière son usage. Le Scrum Master doit connaître Jira et le JQL :

pour comprendre l’outil utilisé par l’équipe
pour être crédible dans ses échanges
pour détecter les usages dysfonctionnels
pour accompagner le Product Owner et l’équipe

Mais pas pour devenir le “gardien du sprint”.

La responsabilité du suivi du sprint appartient au Product Owner

C’est ici que beaucoup d’organisations se trompent. Le Product Owner doit maîtriser Jira et le JQL. C’est à lui :

de surveiller le bon déroulement du sprint
de détecter les signaux de dérive
d’en discuter avec l’équipe
d’alerter les parties prenantes si nécessaire

👉 C’est précisément pour cela que j’ai écrit « Top 15 des requêtes Jira JQL qu’un Product Owner doit maîtriser ».

Quand cette responsabilité est déplacée vers le Scrum Master, on crée un PO dépendant, un SM surchargé et une équipe infantilisée.

Le rôle réel du Scrum Master face à Jira

Le Scrum Master ne “pilote” pas Jira. Il accompagne l’usage de Jira.

Le Scrum Master comme formateur

Quand le Product Owner ne maîtrise pas Jira ou le JQL, le Scrum Master transmet :

les bases de l’outil
les bonnes pratiques
les usages utiles (et ceux à éviter)

Objectif : le Scrum Master doit ne plus être nécessaire et doit s’éclipser progressivement.

Le Scrum Master comme mentor

Quand le Product Owner sait utiliser Jira mais peine à interpréter les signaux,
le Scrum Master aide à :

lire entre les lignes
relier les données au contexte réel
éviter les conclusions hâtives
poser les bonnes questions à l’équipe

Ici, le JQL n’est pas une réponse, mais un support de réflexion et un outil d’aide à la décision.

Le Scrum Master comme leader de l’autonomie

Le mot leader peut gêner, mais c’est bien de cela qu’il s’agit. Pas un leader hiérarchique, mais un leader de la responsabilisation.

Le Scrum Master agit pour que :

le Product Owner devienne autonome
l’équipe prenne en charge son fonctionnement
Jira cesse d’être un outil de contrôle
le système fonctionne sans béquille

Un Scrum Master efficace est un Scrum Master dont l’utilité diminue avec le temps.

Pourquoi la demande de JQL au Scrum Master est souvent un symptôme

Quand une organisation attend du Scrum Master qu’il “sorte des requêtes”, cela révèle rarement un besoin technique. Cela révèle plutôt :

un manque de confiance
une gouvernance produit faible
une peur du flou
une difficulté à assumer les rôles

Le JQL devient alors un outil de substitution à un problème organisationnel non traité.

Jira montre une représentation du travail, pas le travail réel

Jira est un outil déclaratif. Il montre :

✅ ce qui est saisi
✅ quand c’est saisi
✅ de la manière dont c’est saisi

Il ne montre pas :

❌ les arbitrages
❌ les tensions
❌ les compromis
❌ les discussions
❌ les non-dits

Un Scrum Master qui se limite à Jira observe une mise en scène du travail, pas sa réalité.

Conclusion – Le Scrum Master n’a pas besoin de plus de Jira JQL, mais de plus de discernement

Le Scrum Master doit connaître Jira et le JQL. Mais sa valeur n’est pas là. Sa valeur est dans sa capacité à :

développer l’autonomie du Product Owner
accompagner l’équipe vers plus de maturité
résister à la tentation du contrôle
rappeler que l’agilité repose sur la confiance, pas sur les tableaux

Le Scrum Master n’est pas un subalterne chargé de surveiller Jira. C’est un professionnel dont le rôle est de rendre les autres autonomes.

Et c’est précisément pour cela qu’il n’a presque pas besoin de Jira JQL ! 😉