Sprint Backlog
Choisir un objectif réalisable et organiser le travail pour l’atteindre.
Le Sprint Backlog comprend l’objectif du sprint, les éléments retenus dans le Product Backlog et le plan de travail de l’équipe.
Les issues sélectionnées sont regroupées dans le milestone du sprint sur GitLab. Elles évoluent pendant le travail.
Préparer le sprint en équipe¶
| Étape | Décision à prendre |
|---|---|
| Définir l’objectif | Quel résultat voulons-nous pouvoir présenter ? |
| Examiner le temps disponible | Combien de travail pouvons-nous réellement prendre en charge ? |
| Sélectionner et préciser les issues | Que faut-il réaliser pour atteindre cet objectif ? |
| Organiser les contributions | Qui intervient, dans quel ordre et avec quelles dépendances ? |
La planification implique toute l’équipe. Le Scrum Master facilite les échanges et veille à ce que les décisions soient comprises par chacun.
Pour chaque sprint, le rédacteur prévu dans la répartition des documents de suivi rédige la synthèse du plan initial. Son travail est évalué individuellement selon les règles des documents de suivi. Les décisions de planification et la préparation des issues restent un travail collectif ; l’équipe relit la synthèse avant son dépôt.
Définir un objectif concret
Formulez l’objectif en une ou deux phrases décrivant le résultat attendu.
Par exemple, pour le Sprint 1 :
Permettre de jouer une courte partie dans un niveau manuel, depuis le lancement jusqu’à la victoire ou la défaite, puis de recommencer.
Choisissez les issues qui contribuent à cet objectif et respectent les attentes du sujet. Les idées supplémentaires restent dans le Product Backlog tant qu’elles ne sont pas retenues pour le sprint.
Estimer un volume de travail réaliste¶
Une estimation sert à discuter et à choisir. Elle peut être révisée.
Estimez approximativement l’effort restant nécessaire à chaque issue, en heures-personnes : le temps cumulé des personnes qui y contribuent.
| Exemple | Effort total |
|---|---|
| Une personne travaille pendant 2 heures. | 2 heures-personnes. |
| Deux personnes travaillent ensemble pendant 1 heure. | 2 heures-personnes. |
Des valeurs arrondies, comme 1, 2 ou 4 heures, suffisent généralement. L’estimation comprend la réalisation, les tests, la relecture et l’intégration nécessaires à l’issue.
Tenir compte des séances restantes
Après la séance de planification, le calendrier prévoit :
Sprints 1, 2 et 4 : deux séances de travail de 2 heures.
Sprint 3 : une séance de travail de 2 heures.
Pour une équipe de huit personnes présentes aux deux séances, cela représente au maximum 8 × 4 = 32 heures-personnes. Pour sept personnes, cela représente 28 heures-personnes. Le Sprint 3 dispose respectivement de 16 ou 14 heures-personnes.
Ce sont des volumes théoriques. Tenez compte des disponibilités réelles et gardez une marge pour la coordination et les imprévus.
Ne recomptez pas le temps déjà utilisé pendant la planification. Le résultat doit être prêt pour la séance de présentation du livrable.
Construisez un plan permettant de réaliser l’essentiel du travail pendant les séances prévues.
Si une estimation semble difficile
Discutez de ce qui reste incertain : compréhension d’un script, comportement à vérifier, dépendance ou difficulté technique.
Si nécessaire, découpez l’issue ou prévoyez une courte exploration avec un résultat précis attendu, par exemple vérifier qu’une salle peut être chargée et parcourue.
Vérifiez aussi qu’une seule personne ne concentre pas trop de travail et que les dépendances permettent aux autres membres d’avancer. Une charge totale raisonnable ne garantit pas, à elle seule, que le planning est réalisable.
Ces estimations ne nécessitent pas un relevé détaillé du temps passé. Un écart devra être analysé pour améliorer la planification suivante.
Préparer les issues sélectionnées¶
Avant de commencer, chacun doit comprendre le résultat à obtenir.
Pour chaque issue retenue :
Précisez le résultat et les critères d’acceptation.
Désignez un responsable du suivi et les autres contributeurs prévus.
Identifiez les dépendances importantes.
Associez l’issue au milestone du sprint.
Le responsable du suivi ne réalise pas nécessairement tout le travail. Les contributions peuvent inclure du développement, des ressources, de la documentation, des tests ou de la relecture.
Les manipulations sont expliquées dans le tutoriel GitLab Issues.
Cas du Sprint 3
L’objectif porte sur les tests des jeux des deux autres équipes. Identifiez chaque jeu, son équipe et la version à tester.
Répartissez les membres et le temps disponible entre les deux jeux. Prévoyez la prise en main, les scénarios, la reproduction des bugs, leur analyse et la rédaction d’un rapport avec une section par jeu.
Les issues de votre sprint organisent votre travail de test. Elles peuvent référencer les fiches de bugs de votre rapport. Les équipes testées créent ensuite leurs propres issues de correction à partir des retours reçus.
Format et dépôt sur Moodle¶
Une courte synthèse conserve votre plan initial.
| Rendu | Échéance | Fichier dans le dépôt de l’équipe |
|---|---|---|
| Sprint Backlog 1 initial | 24/10/2026 | docs/sprint-1-initial.md |
| Sprint Backlog 2 initial | 19/12/2026 | docs/sprint-2-initial.md |
| Sprint Backlog 3 initial | 13/02/2027 | docs/sprint-3-initial.md |
| Sprint Backlog 4 initial | 27/03/2027 | docs/sprint-4-initial.md |
Les horaires limites sont indiqués dans le calendrier.
Modèle de plan initial
# Sprint [numéro] — Plan initial
Équipe : ...
Rédacteur : ...
Période du sprint : ...
Milestone GitLab : ...
## Objectif
Résultat que l’équipe souhaite obtenir à la fin du sprint.
## Temps disponible
- Séances de travail restantes et disponibilités : ...
- Capacité totale estimée : ... heures-personnes.
- Effort total retenu : ... heures-personnes.
- Marge conservée et raisons : ...
## Travail retenu
| Issue et résultat attendu | Effort estimé, en heures-personnes | Responsable du suivi et contributeurs |
| --- | --- | --- |
| [Numéro et titre](URL de l’issue) — résultat en une phrase. | ... | ... |
## Organisation et points à surveiller
- Ordre de réalisation et dépendances importantes : ...
- Principales incertitudes : ...
- Simplifications envisageables si nécessaire : ...Ajoutez une ligne par issue sélectionnée, dans l’ordre de réalisation envisagé. Indiquez les travaux qui peuvent avancer en parallèle lorsque cela aide à comprendre votre organisation.
Les descriptions détaillées et les critères d’acceptation restent dans GitLab Issues.
Le rédacteur effectue le dépôt sur Moodle sous son propre nom. Il indique son nom, celui de l’équipe et le numéro du sprint, puis fournit un lien permanent vers la version remise du plan initial, en suivant le guide d’organisation du dépôt.
Le lien conserve le contenu de ce fichier : objectif, sélection, estimations et organisation. Il ne fige pas les issues ni le milestone auxquels le document renvoie.
Documentation GitLab : obtenir un lien permanent.
Ce qui est évalué¶
Consultez la grille de la synthèse du Sprint Backlog concerné sur Moodle. La note individuelle porte sur la fidélité au plan initial décidé par l’équipe, l’explication des choix de planification et la clarté de la synthèse. Le lecteur doit retrouver l’objectif, les priorités, la sélection des tâches et leur organisation.
La qualité de la planification collective et de son suivi au cours du sprint est évaluée dans le livrable correspondant. La synthèse conserve le plan de départ ; les issues rendent compte de son évolution.
Adapter le sprint pendant le travail¶
Le plan initial sert de référence pour comprendre les adaptations.
Conservez cette synthèse initiale. Le suivi courant continue dans les issues et le milestone, sans tenir à jour une seconde liste d’avancement dans le document.
Lorsqu’un changement est nécessaire, discutez-en en équipe, mettez à jour les issues concernées et expliquez la décision dans les notes de réunion prévues au calendrier. Un changement de l’objectif ou du périmètre convenu doit être discuté avec les encadrants.
Le bilan du sprint permettra de comparer le résultat avec le plan initial et d’expliquer les écarts. Aucun dépôt supplémentaire de ce plan n’est demandé en fin de sprint.