À propos de ce modèle
La plupart des équipes planifient leurs sprints dans des tickets Jira et un backlog, puis perdent de vue le moment où chaque élément est vraiment livré. Une vue Gantt d'un seul sprint révèle le planning réel : quand la conception passe le relais au développement, quand chaque story est en revue, quand la QA la récupère, quand a lieu la démo. Ce modèle de 2 semaines peut être dupliqué pour chaque sprint, ou servir à planifier une release plus longue comme une chaîne de sprints.
Comment se découpe un sprint de 2 semaines
Lancement du sprint
Réunion de sprint planning : revue du backlog, estimation des stories, capacité face à la vélocité, objectif du sprint. Vérifiez que chacun a ses stories assignées. Terminez par un objectif de sprint en une phrase que n'importe qui dans l'équipe peut réciter.
- Affinage du backlog
- Estimation des story points
- Vérification capacité vs vélocité
- Attribution des stories
- Objectif du sprint
Jours 2–4 — Conception et démarrage
Les designers finalisent les specs restantes. Les développeurs démarrent d'abord par les stories les plus grosses (pour avancer le risque dans le sprint). Réunion quotidienne à la même heure chaque jour — 15 minutes, trois questions par personne.
- Réunion quotidienne
- Le designer transmet les specs
- Les développeurs démarrent les plus grosses stories
- Modèle de PR et SLA de revue confirmés
Jours 5–8 — Développement
Développement intensif. Les revues de code se font en continu (objectif : PR ouverte moins de 24 heures avant la première revue). Point à mi-sprint le jour 7 — signalez toute story à risque de retard.
- Réunion quotidienne
- Revues de code (SLA 24h)
- Point à mi-sprint (jour 7)
- Recalibrage des stories à risque
Jours 9–11 — QA et fusion
Les stories sont terminées et prêtes pour la QA. Les corrections issues de la QA repartent vers les développeurs. À la fin du jour 11, toute story livrable est fusionnée. Ce qui n'a pas abouti retourne au backlog.
- Passage QA sur les stories terminées
- Cycle de correction de bugs
- Fusion vers main
- Mise à jour des notes de version
Jours 12–14 — Démo et rétro
Jour 12 : déploiement en staging, tests de fumée. Jour 13 : démo du sprint devant les parties prenantes — chaque responsable de story présente son travail. Jour 14 : rétrospective — ce qui a bien marché, ce qui a ralenti l'équipe, ce qu'il faut essayer au prochain sprint. Planifiez le lancement du prochain sprint.
- Déploiement en staging
- Tests de fumée
- Démo du sprint
- Rétrospective
- Lancement du prochain sprint
Conseils d'équipes qui enchaînent des sprints fluides
- Démarrez d'abord par la story la plus grosse. Avancez le risque dans le sprint, ne le repoussez pas.
- Ouvrez chaque PR dans les 24 heures suivant la fin du travail. Les PR non ouvertes sont des retards silencieux.
- Faites le point à mi-sprint le jour 7. Les stories à risque au jour 7 sont encore rattrapables ; au jour 12, non.
- Terminez chaque rétrospective par un changement concret pour le prochain sprint. Des listes de 15 idées ne produisent aucun changement.
- Faites la démo même si la moitié des stories n'a pas abouti. Montrer un travail partiel crée une pression pour livrer.
Questions fréquentes
Le Gantt est-il utile pour des sprints agiles ?
Oui — pour la vue d'un seul sprint, il rend visibles l'enchaînement des stories et les transmissions d'une façon qu'un tableau Kanban ne permet pas.
Faut-il faire ça à chaque sprint ?
Un Gantt de sprint unique est surtout utile pour les 3 à 5 premiers sprints d'une nouvelle équipe, ou pour tout sprint avec des dépendances transverses.
Puis-je enchaîner plusieurs sprints dans un plan de release ?
Oui. Ouvrez ce modèle, puis ajoutez 2 à 3 blocs de 2 semaines supplémentaires pour obtenir une vue au niveau de la release.