Après la revue de sprint, il est important de prendre un moment en équipe pour réfléchir à la façon dont le sprint s’est déroulé et décider comment vous voulez travailler pour la suite.

Cette page t’explique comment mener une rétrospective simple et comment mettre à jour ton backlog dans Jira pour refléter l’état réel du projet et préparer le sprint 2.

Pourquoi faire une rétrospective ?

• Identifier ce qui a bien fonctionné pendant le sprint pour pouvoir le garder et le renforcer.
• Repérer ce qui a moins bien fonctionné (organisation, communication, techniques) pour l’améliorer.
• Décider 1–2 actions concrètes à mettre en place dès le prochain sprint (plutôt que de rester dans des généralités).

Format simple de rétrospective

Tu n’as pas besoin d’un atelier complexe : un format léger mais honnête suffit pour ce cours.

• Ce qu’on garde : listez 2–3 choses qui ont bien fonctionné (ex. utilisation de Jira, communication, organisation des réunions, etc.).
• Ce qu’on veut améliorer : listez 2–3 aspects qui ont posé problème (ex. gestion du temps, manque de tests, branches Git mal gérées, etc.).
• Actions concrètes : choisissez 1–2 actions précises à appliquer dès le sprint 2 (ex. fixer un daily court, écrire des tests pour les modules critiques, mieux préparer les revues de code).

Documenter ta rétrospective

La rétrospective doit laisser une trace pour que vous puissiez vous y référer plus tard (et pour que l’enseignant voie votre démarche).

• Créez une issue dédiée dans Jira (par exemple « Rétrospective – Sprint 1 ») ou un petit document dans docs/.
• Notez-y brièvement ce que vous gardez, ce que vous voulez améliorer et les actions concrètes décidées.
• Assignez les actions à des membres de l’équipe et/ou créez des tâches associées dans le backlog du sprint 2.

Mettre à jour le backlog après le sprint 1

La fin du sprint 1 est un bon moment pour remettre ton backlog en ordre avant d’attaquer le sprint 2.

• Marque comme terminées les stories réellement complétées pendant le sprint (en vérifiant que les critères d’acceptation sont bien remplis).
• Pour les stories commencées mais non terminées, décide si tu les scindes (partie faite / partie à faire) ou si tu les reportes telles quelles au sprint suivant.
• Ajoute au backlog les nouvelles idées ou besoins identifiés pendant la revue (par exemple des améliorations, des corrections, des ajustements).
• Revois rapidement les priorités pour préparer la sélection des stories du sprint 2.

Lier la rétrospective au backlog

La rétrospective n’a de valeur que si elle débouche sur des changements concrets dans la façon de travailler.

• Pour chaque action décidée en rétro, crée une tâche ou une story dans Jira (par exemple « Mettre en place un daily de 10 minutes » ou « Ajouter des tests unitaires pour le module X »).
• Inclue certaines de ces actions dans le sprint 2, au même titre que des fonctionnalités pour le client.
• Lors de la rétro du sprint 2, reviens voir si ces actions ont été réalisées et si elles ont aidé.

Ce que tu dois avoir après cette étape

• Une rétrospective de sprint 1 documentée (issue ou document) avec points positifs, points à améliorer et actions concrètes.
• Un backlog Jira mis à jour : stories terminées clairement identifiées, stories reportées ou ajustées, nouvelles stories ajoutées si nécessaire.
• Quelques actions d’amélioration prêtes à être prises en compte dans la préparation du sprint 2.