Articles
Planification de sprint asynchrone : est-ce vraiment possible ?

Kelly Lewandowski
Dernière mise à jour 25/03/20267 min de lecture
Le problème d'une planification entièrement synchrone
- 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é
Ce qui fonctionne vraiment en asynchrone
Revue du backlog et mise en contexte
Estimation
Capacité et disponibilité
Vérifications de la Définition de Prêt

Ce qui nécessite encore un appel en direct
Négociation de l'objectif de sprint
Engagement sur le périmètre
Éléments à forte ambiguïté
Le modèle hybride
Asynchrone : partager les candidats (2 jours avant)
Asynchrone : signaler les blocages (1 jour avant)
Synchrone : aligner et s'engager (30-60 minutes)

Quand rester entièrement synchrone
- 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
| Pratique | Pourquoi c'est important |
|---|---|
| Fixer une deadline pour les votes | Sans elle, l'estimation s'étire indéfiniment |
| Utiliser le dimensionnement relatif | Fibonacci ou tailles de t-shirt fonctionnent mieux en asynchrone que les estimations basées sur les heures |
| Afficher le contexte avec chaque story | Les critères d'acceptation, les maquettes et les dépendances doivent être joints, pas seulement liés |
| Signaler automatiquement les votes divergents | Des 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 courtes | Ne déposez pas 30 stories d'un coup. Regroupez-les en lots de 5 à 8 |
Un calendrier réaliste
- 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
- Deadline d'estimation
- L'équipe signale les éléments nécessitant une discussion
- Le product owner répond aux questions ouvertes
- Session synchrone de 30 à 60 minutes : confirmer l'objectif, résoudre les signalements, s'engager sur le périmètre
- Le sprint commence