85% des problèmes de sprint viennent du planning

85% des problèmes que tu règles pendant ton sprint ont été créés le lundi au planning.

C'est pas une stat académique... C'est ce que j'observe depuis des années sur le terrain. Et chaque fois que je le dis, j'entends la même réponse : "Ouais mais les urgences, on peut pas les prévoir."

Tu peux anticiper les urgences en regardant d'où elles viennent vraiment.

Le sprint goal était flou (ou absent) : Alors quand une demande arrive en milieu de sprint, personne sait si c'est urgent ou pas. Par défaut, tout devient urgent.

La capacité de l'équipe a été surestimée : Pas de buffer, pas de place pour la maintenance. Le sprint commence déjà en retard avant qu'on ait commis une seule ligne de code.

Le backlog était pas prêt : Les stories ont été découvertes pendant la réunion. Les décisions ont été prises sous pression, en 2h, avec les mauvaises informations.

Résultat, tu passes les deux semaines suivantes à réagir, relancer, réajuster. Tu es (très) occupé. Et complètement invisible parce que tu gères du bruit, pas de la valeur.

Le piège classique c'est de penser que le planning, c'est le territoire du PO. Que t'approcher du backlog, c'est faire le PM "déguisé". Alors tu te mets de côté. Tu facilites la réunion. Tu gères le temps.

Et le sprint qui suit, tu te retrouves en mode pompier.
Pis le sprint d'après aussi...
Au 15e sprint en mode pompier, quelqu'un te dit : "Tu devais pas coacher le PO là-dessus ?"

Oui. C'était exactement ton rôle.

🧪 Ton expérimentation 48h

La question de capacité

Avant d'ouvrir la réunion, tu vas voir le PO avec un chiffre. Jours dispo, absences, maintenance incluse. Et tu poses cette question :

"Quelles sont les stories qu'on peut pas se permettre de ne pas livrer ce sprint ?"

Contre-intuitive. Elle force une vraie priorisation, pas une liste de souhaits. Le PO choisit avant d'entrer dans la salle, l'équipe aussi. Ce qui rentre dans le sprint a déjà été défendu.

La vision avant la formulation

Le sprint goal ne s'invente pas pendant le planning. Mais on se l'approprie.

Le PO arrive avec une intention claire : ce qu'on cherche à sécuriser, le feedback qu'on veut obtenir, la valeur qu'on veut livrer. Pas un paragraphe, juste une direction. L'équipe formule ensuite ses mots. Elle s'approprie l'objectif au lieu de le subir.

Si le PO peut pas te dire ça en 2 min. le vendredi avant, la réunion du lundi va être longue...

Le % non-négociable

La dette technique, t'essaieras pas de la justifier en réunion, tu vas perdre. Le PO veut des features. Le management veut du delivery.

Ce qui marche : négocier un pourcentage de capacité réservé à la maintenance et à l'amélioration technique. Le pourcentage varie selon le contexte. Le principe, lui, ne bouge pas.

C'est exactement le principe de l'épargne. Tu mets de côté avant de dépenser, pas avec ce qui reste à la fin du mois. Ce qui reste à la fin du sprint, c'est zéro. Ça l'a toujours été.

Super PC, et si j'ai pas le temps pour les trois ?

Une seule question au PO, dans le couloir, avant lundi :

"Shit happens. Ça arrive à chaque sprint. C'est quoi le scope que tu veux absolument protéger ?"

En général ça fait sourire. Et ça force la vraie conversation. Sur les priorités réelles, pas les priorités déclarées.

Est-ce que t'as déjà essayé de négocier un % fixe pour la dette technique ? Comment ça s'est passé ?

Allez, A+
Pierre-Cyril (mais tu peux m'appeler PC)