Articles

Planification de sprint asynchrone : est-ce vraiment possible ?

Des membres d'une équipe distribuée travaillant depuis différents endroits, avec des éléments de planification flottant entre eux, reliés par des lignes pointillées
Kelly Lewandowski

Kelly Lewandowski

Dernière mise à jour 25/03/20267 min de lecture

La planification de sprint est l'une des rares cérémonies Scrum où toute l'équipe doit repartir avec la même compréhension de ce qu'elle construit et pourquoi. Cela en fait un candidat difficile pour passer entièrement en asynchrone. Pourtant, la majeure partie de ce qui se passe dans une réunion de planification de deux heures ne nécessite pas que tout le monde soit dans la même salle (ou sur le même appel) en même temps. Les équipes qui pratiquent bien la planification asynchrone ne sautent pas la conversation. Elles déplacent simplement les parties lecture et réflexion hors de la réunion, afin que le temps en direct soit consacré aux décisions réelles.

Le problème d'une planification entièrement synchrone

Une réunion de planification de sprint typique dure 1 à 2 heures pour un sprint de deux semaines. En pratique, une grande partie de ce temps est consacrée à des activités qui ne bénéficient pas d'une discussion en temps réel :
  • Lire les tickets qui auraient pu être examinés au préalable
  • Poser des questions de clarification auxquelles le product owner aurait pu répondre par écrit
  • Attendre que le lecteur le plus lent soit prêt avant de passer à l'élément suivant
  • Réexpliquer un contexte qui existe déjà dans le backlog mais que personne n'a consulté
Pour les équipes distribuées sur plusieurs fuseaux horaires, le problème s'amplifie. Quelqu'un prend toujours la réunion à une heure peu commode. Et un coéquipier fatigué à 22 h ne contribue pas à la réflexion sur la capacité avec toute sa vivacité.

Ce qui fonctionne vraiment en asynchrone

Certaines parties de la planification se prêtent bien à l'asynchrone sans rien perdre :

Revue du backlog et mise en contexte

Le product owner partage les éléments candidats pour le sprint, accompagnés de l'objectif de sprint proposé, 1 à 2 jours avant la planification. Les membres de l'équipe les examinent à leur rythme, posent des questions en commentaires et signalent tout ce qui est peu clair. Au moment de la réunion, tout le monde a déjà lu et assimilé le travail.

Estimation

C'est la partie qui se transpose le mieux en asynchrone. Des outils comme le planning poker de Kollabe permettent aux membres de l'équipe d'estimer les stories de façon indépendante, sans le biais d'ancrage qui survient quand on entend d'abord le chiffre d'un développeur senior. Chaque personne examine la story, attribue son estimation et passe à la suivante. Les désaccords apparaissent naturellement quand les votes divergent, et ces éléments spécifiques peuvent être signalés pour une discussion synchrone. Pour approfondir la façon de mener l'estimation sans appel en direct, consultez notre guide sur le planning poker asynchrone.

Capacité et disponibilité

Congés, jours de formation, rotations d'astreinte. Ces informations peuvent vivre dans un document partagé ou un fil Slack. Personne n'a besoin d'une réunion pour dire « Je suis absent jeudi et vendredi. »

Vérifications de la Définition de Prêt

Savoir si chaque élément du backlog satisfait à la Définition de Prêt de l'équipe est une vérification simple oui/non. Les membres de l'équipe peuvent examiner les éléments par rapport aux critères de façon asynchrone et signaler les lacunes au product owner avant la session synchrone. Un membre de l'équipe examinant les éléments du backlog de sprint sur un ordinateur portable, avec des coches et des points d'interrogation apparaissant au-dessus de différents éléments

Ce qui nécessite encore un appel en direct

Passer entièrement en asynchrone, c'est là que les équipes se brûlent généralement. Certaines parties de la planification ont besoin de la rapidité des échanges qu'offre uniquement une conversation en temps réel.

Négociation de l'objectif de sprint

L'objectif de sprint est un engagement sur ce que l'équipe optimise durant ce cycle. Quand les priorités s'affrontent ou que l'objectif n'est pas évident, cette discussion doit se faire en direct. Les fils asynchrones sur des priorités concurrentes ont tendance à s'étirer sur des jours sans résolution. Quand vous ne parvenez vraiment pas à résoudre quelque chose de façon asynchrone, la voie la plus rapide est parfois la plus simple. Des équipes ont été connues pour tirer à pile ou face afin de dénouer une impasse sur des décisions à faible enjeu plutôt que de programmer encore une autre réunion. Cela peut sembler saugrenu, mais c'est préférable à un fil Slack de trois jours sur le fait de prioriser la refonte du tableau de bord ou le nettoyage de l'API.

Engagement sur le périmètre

Après l'estimation et la revue asynchrones, l'équipe a besoin d'un moment pour regarder l'ensemble ensemble : l'objectif de sprint, les éléments sélectionnés, la capacité. « Pouvons-nous vraiment faire cela ? » est une question à laquelle il vaut mieux répondre en groupe, où quelqu'un peut dire « c'est trop » et où l'équipe peut négocier en temps réel.

Éléments à forte ambiguïté

Si une story a des exigences peu claires ou un risque technique réel, les commentaires asynchrones ne suffiront pas. Ces éléments nécessitent un tableau blanc ou au moins une conversation ciblée où les gens peuvent discuter des options en temps réel.

Le modèle hybride

Faites la préparation en asynchrone. Réservez la session en direct pour l'alignement et les décisions. Voici à quoi cela ressemble en pratique :
Asynchrone : partager les candidats (2 jours avant)
Le product owner publie l'objectif de sprint proposé et les éléments candidats du backlog. L'équipe les examine, pose des questions et effectue les estimations à l'aide d'un outil de planning poker asynchrone.
Asynchrone : signaler les blocages (1 jour avant)
Les membres de l'équipe marquent les éléments qu'ils ne peuvent pas estimer avec confiance, partagent leur capacité et notent leurs préoccupations. Le product owner résout les questions ouvertes.
Synchrone : aligner et s'engager (30-60 minutes)
Revoir l'objectif de sprint ensemble. Discuter uniquement des éléments signalés. Confirmer le périmètre par rapport à la capacité. Repartir avec un engagement partagé.
Les équipes utilisant ce modèle réduisent régulièrement leur temps de planification synchrone de deux heures à 30-60 minutes. La réunion se transforme en session de prise de décision plutôt qu'en marathon de lecture et de discussion. Une équipe lors d'un court appel vidéo avec un tableau d'ordre du jour clair montrant seulement trois éléments de discussion signalés

Quand rester entièrement synchrone

La planification asynchrone ne convient pas à toutes les équipes. Conservez la réunion complète si :
  • Votre équipe est nouvelle. Les personnes qui n'ont pas encore construit un contexte partagé ont besoin de plus de contact visuel pour calibrer les attentes et établir la confiance.
  • Vous êtes au début de l'adoption de Scrum. La structure d'une cérémonie complète aide jusqu'à ce que les habitudes soient ancrées.
  • Le travail est principalement exploratoire. Si la plupart des éléments du sprint sont axés sur la recherche, vous passerez de toute façon plus de temps à discuter qu'à estimer.
  • Votre backlog est un chaos. La planification asynchrone suppose que les éléments arrivent prêts. Si ce n'est pas le cas, vous consumerez le temps synchrone à démêler des tickets à moitié rédigés.

Faire fonctionner l'estimation asynchrone

Si l'estimation est la partie que vous déplacez en asynchrone, quelques pratiques aident :
PratiquePourquoi c'est important
Fixer une deadline pour les votesSans elle, l'estimation s'étire indéfiniment
Utiliser le dimensionnement relatifFibonacci ou tailles de t-shirt fonctionnent mieux en asynchrone que les estimations basées sur les heures
Afficher le contexte avec chaque storyLes critères d'acceptation, les maquettes et les dépendances doivent être joints, pas seulement liés
Signaler automatiquement les votes divergentsDes outils comme Kollabe mettent en évidence quand les estimations sont très éloignées afin que vous sachiez quoi discuter en synchrone
Garder des rondes courtesNe déposez pas 30 stories d'un coup. Regroupez-les en lots de 5 à 8
Si vous n'êtes pas sûr de la complexité d'une story avant l'estimation, l'Analyseur de complexité d'estimation peut vous aider à décider si quelque chose nécessite une discussion en groupe ou peut être estimé de façon indépendante.

Un calendrier réaliste

Voici à quoi ressemble une planification axée sur l'asynchrone pour une équipe exécutant des sprints de deux semaines : Mercredi (2 jours avant le début du sprint) :
  • Le product owner partage les éléments candidats et l'ébauche de l'objectif de sprint
  • L'équipe commence la revue et l'estimation asynchrones
Jeudi (1 jour avant) :
  • Deadline d'estimation
  • L'équipe signale les éléments nécessitant une discussion
  • Le product owner répond aux questions ouvertes
Vendredi (début du sprint) :
  • Session synchrone de 30 à 60 minutes : confirmer l'objectif, résoudre les signalements, s'engager sur le périmètre
  • Le sprint commence
Investissement en temps total par personne : moins de deux heures, environ la même chose qu'une seule réunion de planification traditionnelle. La différence, c'est qu'il est réparti sur trois jours, et la majeure partie se déroule quand c'est pratique pour chaque personne.

Commencer petit

La planification de sprint asynchrone fonctionne quand vous la traitez comme un moyen de rendre votre temps synchrone plus ciblé, et non comme un remplacement total de la conversation. Déplacez d'abord l'estimation et la revue du backlog en asynchrone. Gardez la définition des objectifs et l'engagement en synchrone. Voyez ce dont votre équipe a réellement besoin à partir de là, et non ce qui semble efficace en théorie.

Techniquement oui, mais la plupart des équipes constatent que l'engagement sur le périmètre et les discussions sur l'objectif de sprint fonctionnent mieux en direct. Une approche hybride — préparation asynchrone avec une courte session synchrone — tend à produire de meilleurs résultats.

Avec une bonne préparation asynchrone, 30 à 60 minutes suffisent généralement. Si vous dépassez régulièrement une heure, votre préparation asynchrone nécessite probablement des améliorations.

Vous avez besoin d'un outil de backlog (Jira, Linear, etc.) associé à un outil d'estimation asynchrone comme le planning poker de Kollabe. La communication passe par les canaux habituels de votre équipe — Slack, Teams ou similaires.

C'est possible, bien que les bénéfices soient moindres. Les équipes co-localisées gagnent principalement du temps en ayant les personnes qui examinent les éléments de façon indépendante plutôt qu'en lisant ensemble dans une salle.