Modèle de diagramme de Gantt pour le sprint planning
Un sprint agile de 2 semaines visualisé comme un Gantt : planification, réunions quotidiennes, conception, développement, revue de code, QA, démo, rétrospective — pour les équipes qui veulent voir dates et dépendances du sprint en un seul coup d'œil.
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
01
Lancement du sprint
Jour 1
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
02
Jours 2–4 — Conception et démarrage
Jours 2–4
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
03
Jours 5–8 — Développement
Jours 5–8
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
04
Jours 9–11 — QA et fusion
Jours 9–11
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
05
Jours 12–14 — Démo et rétro
Jours 12–14
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
01Démarrez d'abord par la story la plus grosse. Avancez le risque dans le sprint, ne le repoussez pas.
02Ouvrez chaque PR dans les 24 heures suivant la fin du travail. Les PR non ouvertes sont des retards silencieux.
03Faites le point à mi-sprint le jour 7. Les stories à risque au jour 7 sont encore rattrapables ; au jour 12, non.
04Terminez chaque rétrospective par un changement concret pour le prochain sprint. Des listes de 15 idées ne produisent aucun changement.
05Faites 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.