Sprint Review
Exploiter les retours, comprendre le travail réalisé et décider des prochaines actions.
Dans ce projet, le compte rendu de Sprint Review rassemble deux parties :
| Partie | Question principale |
|---|---|
| Retours sur le produit | Que nous apprend le résultat présenté et que faut-il en retenir pour la suite ? |
| Rétrospective de l’équipe | Qu’est-ce qui nous a aidés ou freinés, et comment améliorer notre façon de travailler ? |
Un compte rendu de la réunion d’équipe est demandé après les livrables 1, 2 et 4.
| Présentation et réunion | Dépôt Moodle |
|---|---|
| Livrable 1 — 30/11/2026 | 05/12/2026 |
| Livrable 2 — 01/02/2027 | 06/02/2027 |
| Livrable 4 — 24/05/2027 | 29/05/2027 |
Les horaires limites figurent dans le calendrier. Après le livrable 3, les retours alimentent le rapport de tests prévu au calendrier ; aucun compte rendu de Sprint Review supplémentaire n’est demandé.
Le compte rendu porte sur le produit et le fonctionnement collectif. Chaque membre remet également son bilan individuel de sprint sur Moodle, à la même échéance. Pour le Sprint 3, ce bilan individuel est dû le 20/03/2027, comme le rapport de tests.
Conduire la réunion¶
Les notes commencent pendant la présentation et les questions. Le rédacteur prévu dans la répartition des documents de suivi conserve les remarques utiles des encadrants et des autres équipes. Les autres membres peuvent l’aider à recueillir ces retours.
La réunion d’équipe qui suit dispose de 30 minutes. Le Scrum Master facilite les échanges et veille à ce que chacun puisse contribuer. Le rédacteur prépare le compte rendu, dont l’équipe vérifie le contenu. Son travail est évalué individuellement selon les règles des documents de suivi.
| Étape | Travail à réaliser ensemble |
|---|---|
| Rappeler l’objectif | Résumer ce que le sprint devait produire et le résultat effectivement obtenu. |
| Examiner les retours | Clarifier les remarques reçues et décider de leur suite. |
| Faire la rétrospective | Identifier les pratiques utiles, les difficultés et les améliorations possibles. |
| Décider et vérifier | Choisir les prochaines actions, nommer leurs responsables et mettre à jour GitLab. |
Garder une discussion utile
Appuyez-vous sur des faits et des exemples du sprint : une intégration réussie, un blocage, une vérification oubliée ou une décision qui a aidé l’équipe. Décrivez leurs conséquences et cherchez une réponse concrète.
Si un point demande une longue investigation technique, identifiez l’action nécessaire et les personnes qui s’en chargeront.
À partir du deuxième compte rendu, reprenez aussi les actions d’amélioration décidées précédemment : ont-elles été réalisées ? Ont-elles eu l’effet attendu ? Faut-il les poursuivre ou les adapter ?
Contenu du compte rendu¶
Conservez les observations importantes, les décisions et les actions. Résumez le résultat du sprint en quelques lignes. Les liens vers le support de présentation, le backlog et les notes de séance permettent de retrouver les détails du travail réalisé.
Retours sur le produit
Rappelez l’objectif du sprint et indiquez dans quelle mesure il a été atteint. Expliquez les écarts importants et les choix faits pendant le sprint.
Pour les retours qui appellent une décision, précisez si la suggestion est :
Retenue, avec l’action prévue.
Différée, avec la raison et le moment où elle devra être réexaminée.
Écartée, avec une justification.
Appuyez vos décisions sur l’intérêt pour le jeu, les priorités et le temps disponible. Un changement de l’objectif ou du périmètre convenu doit être discuté avec les encadrants.
Rétrospective de l’équipe
Examinez la manière dont vous avez travaillé : répartition des tâches, coordination, entraide, intégration, relectures et tests.
Identifiez ce qui mérite d’être conservé et ce qui demande une amélioration. Pour une difficulté, donnez un exemple et expliquez ses conséquences. Les constats doivent permettre à l’équipe d’agir.
Par exemple :
Constat : plusieurs membres ont vérifié le redémarrage de façons différentes ; un défaut de réinitialisation a été oublié.
Action : Léa prépare un scénario commun couvrant le redémarrage après une victoire et après une défaite, pour la prochaine séance.
Suivi : l’équipe utilise ce scénario et vérifie s’il facilite la détection des problèmes.
Des actions adaptées à la suite du projet
Choisissez quelques actions réalisables. Pour chacune, indiquez un responsable, une échéance ou un prochain point de vérification et un lien vers l’issue concernée, lorsqu’il y en a une.
Les décisions qui changent les tâches, les priorités ou les responsabilités doivent aussi être reportées dans GitLab. Réutilisez les issues existantes ou créez une issue lorsque la décision introduit un travail nouveau.
Après le Sprint 4, le jeu doit être terminé. Les actions restantes concernent la consolidation : jaquette, bande-annonce, publication sur itch.io, préparation de la remise finale et corrections mineures.
Modèle à utiliser¶
Rédigez le compte rendu en Markdown dans le dépôt GitLab de l’équipe :
docs/reviews/sprint-1.mddocs/reviews/sprint-2.mddocs/reviews/sprint-4.md
Modèle à copier
# Sprint Review — Sprint N
- Équipe : ...
- Date de la réunion : ...
- Rédacteur : ...
- Liens utiles : support de présentation, milestone du sprint…
## Retours sur le produit
- Objectif du sprint : ...
- Résultat obtenu et principaux écarts : ...
| Retour important | Décision et justification | Issue concernée |
| --- | --- | --- |
| ... | Retenu, différé ou écarté : ... | Lien si nécessaire. |
## Rétrospective de l’équipe
- Pratiques utiles à conserver, avec exemples : ...
- Difficultés rencontrées et conséquences : ...
- Bilan des actions d’amélioration précédentes, s’il y en a : ...
## Prochaines actions
| Action décidée | Responsable | Échéance ou point de vérification | Issue concernée |
| --- | --- | --- | --- |
| ... | ... | ... | Lien si nécessaire. |Adaptez le nombre de lignes au travail réel. Une échéance peut être « à la prochaine séance » ou « avant le prochain livrable » lorsque ce repère est suffisamment précis pour l’action concernée.
Dépôt sur Moodle¶
Consultez la grille du compte rendu de Sprint Review concerné sur Moodle avant la réunion, puis avant le dépôt. Elle porte sur :
Le bilan du produit et la rétrospective : résultats, retours reçus et fonctionnement de l’équipe, avec des exemples concrets.
Les décisions et leur suivi : raisons des choix, actions prévues et bilan des actions convenues lors de la rétrospective précédente, lorsqu’il y en a.
La qualité de rédaction : un compte rendu clair, concis et utilisable.
La note individuelle apprécie la restitution du travail et des échanges. Les difficultés de l’équipe ne sont pas, à elles seules, un défaut du compte rendu. Signalez les décisions encore ouvertes et les informations manquantes au lieu de les inventer.
Le rédacteur effectue le dépôt sur Moodle sous son propre nom, avec :
Son nom, le nom de l’équipe et le numéro du sprint.
Un lien permanent vers la version remise du compte rendu, en suivant le guide d’organisation du dépôt.
Le compte rendu est préparé pendant les échanges et relu collectivement. Le délai du samedi permet de finaliser sa rédaction et son dépôt. Le suivi des actions continue ensuite dans GitLab.