Product Backlog
Transformer votre proposition de jeu en travail à réaliser et définir les priorités.
Le Product Backlog rassemble les besoins et les améliorations envisagés pour le projet. Il évolue avec vos connaissances, les retours et les résultats des sprints.
Dans ce projet, il est suivi dans GitLab Issues.
Du document de design aux issues¶
| Élément | Rôle |
|---|---|
| Document de design | Décrire le jeu et expliquer les choix. |
| Product Backlog | Identifier et prioriser le travail nécessaire. |
| Sprint Backlog | Organiser le travail retenu pour atteindre l’objectif d’un sprint. |
Une vue d’ensemble et une sélection pour le sprint
Le Product Backlog donne une vue d’ensemble du travail restant. Lors de la planification, vous sélectionnez les éléments utiles à l’objectif du sprint et précisez comment les réaliser.
Dans GitLab, les issues sélectionnées sont associées au milestone du sprint. Elles restent dans le même projet : il est inutile de les recréer ou de les dupliquer.
Préparer le Product Backlog initial¶
Reprenez le document de design après les retours du livrable 0.
Identifiez le travail nécessaire pour obtenir un jeu complet.
Créez les issues correspondantes sur GitLab.
Définissez les priorités en équipe.
Vérifiez ensemble la cohérence du backlog avec le document de design.
Le rendu initial est prévu le 17 octobre 2026, selon les modalités du calendrier.
Que faut-il prévoir ?
Pensez aux différents aspects du projet :
Le fonctionnement du personnage et les règles du jeu.
Les niveaux et leur génération.
L’interface et les informations données au joueur.
Le mode de développement et les tests.
Les instructions permettant à une autre personne de lancer le jeu.
Les supports de présentation et de promotion.
Appuyez-vous sur le sujet et sur votre concept pour déterminer ce qui est nécessaire.
Les éléments réutilisés peuvent aussi demander du travail : les comprendre, les adapter, les intégrer et les vérifier. Décrivez ce travail dans les issues concernées.
Quel niveau de détail ?
Chaque élément doit présenter un besoin compréhensible et un résultat attendu.
À ce stade, certaines fonctionnalités peuvent rester larges. Le découpage en tâches plus précises, l’estimation du travail et la répartition des responsabilités seront approfondis lors de la préparation des Sprint Backlogs.
Il n’est pas nécessaire de prévoir dès maintenant tous les bugs ou toutes les tâches techniques de l’année.
Rédiger des issues utilisables¶
Une issue doit permettre de comprendre le résultat attendu et de vérifier qu’il est obtenu.
| Élément | Attente |
|---|---|
| Titre | Nommer un résultat précis. |
| Description | Expliquer le besoin et les informations utiles. |
| Critères d’acceptation | Indiquer comment vérifier le résultat. |
| Priorité | Montrer l’importance du travail pour le projet. |
Exemple d’issue
Titre : Recommencer une partie après une défaite.
Description : Lorsque le personnage perd, le joueur doit pouvoir relancer le niveau sans fermer le jeu.
Critères d’acceptation :
Une action permettant de recommencer est proposée après la défaite.
Cette action replace le personnage au point de départ et réinitialise les éléments nécessaires du niveau.
Le joueur peut immédiatement reprendre le contrôle.
Ces critères décrivent un comportement observable. Ils serviront également à préparer les vérifications.
Découper et coordonner le travail
Une issue comme « Faire tout le gameplay » doit être précisée et découpée avant sa réalisation.
Privilégiez des éléments que l’équipe peut réaliser, intégrer et vérifier progressivement.
Plusieurs membres peuvent contribuer à une même issue. La planification du sprint permettra de préciser les responsabilités.
Si une issue dépend d’un autre travail, indiquez le lien et expliquez cette dépendance.
Définir les priorités¶
Qu’est-ce qui apporte le plus au projet maintenant ?
Discutez notamment :
Des éléments indispensables pour obtenir un jeu jouable.
Des difficultés à explorer tôt.
Des dépendances entre les travaux.
Des améliorations qui peuvent attendre.
Essentiel, urgent et optionnel
Une fonctionnalité essentielle au jeu final n’est pas forcément la première à développer.
Par exemple, la génération des niveaux est obligatoire, mais le Sprint 1 doit d’abord permettre de jouer dans un niveau manuel.
Les fonctionnalités optionnelles doivent être clairement identifiées. Elles ne doivent pas retarder les éléments nécessaires au sujet.
Rendez les priorités visibles dans GitLab et révisez-les lorsque de nouvelles informations le justifient.
Format et dépôt sur Moodle¶
Le travail quotidien reste suivi dans GitLab Issues.
Pour conserver une trace de vos choix initiaux, créez
docs/product-backlog-initial.md dans le dépôt de l’équipe.
Le Scrum Master rédige cette synthèse et la dépose sur Moodle sous son propre nom, conformément à la répartition des documents de suivi. La qualité de sa synthèse est évaluée individuellement.
Toute l’équipe participe à la création des issues, aux choix de priorité et à la relecture. Chaque membre continue à maintenir les issues sur lesquelles il travaille. La planification et le suivi de chaque Sprint Backlog sont évalués collectivement dans le livrable correspondant.
Tout remplacement du rédacteur doit être convenu avec les encadrants.
Cette courte synthèse contient :
Le nom de l’équipe, le nom du rédacteur et la date.
Le lien vers la liste des issues du projet.
La liste des issues du backlog initial, avec leur résultat attendu et leur priorité.
Quelques phrases expliquant les premiers choix, les éléments optionnels et les principales incertitudes.
Structure de la synthèse
# Product Backlog initial
Équipe : ...
Rédacteur : ...
Date : ...
Liste des issues : ...
## Travail identifié
| Issue | Résultat attendu | Priorité |
| --- | --- | --- |
| [Numéro et titre](URL de l’issue) | Résumé en une phrase. | Haute / moyenne / basse |
## Choix et questions ouvertes
- À traiter en premier : ...
- Éléments optionnels : ...
- Principales difficultés ou décisions à vérifier : ...Ajoutez une ligne par issue. Les descriptions détaillées et les critères d’acceptation restent dans GitLab Issues.
Cette synthèse conserve vos choix au moment du rendu. Elle n’a pas besoin d’être tenue à jour après le dépôt : le backlog de travail continue à évoluer sur GitLab.
Le rédacteur effectue le dépôt sur Moodle sous son propre nom. Il indique son nom, celui de l’équipe et la date, puis fournit un lien permanent vers la version remise de la synthèse, en suivant le guide d’organisation du dépôt.
Le lien permanent conserve la version de la synthèse. Il ne fige pas le contenu des issues auxquelles elle renvoie.
Préparer et remettre le Sprint Backlog.
Ce qui est évalué¶
Consultez la grille de la synthèse du Product Backlog sur Moodle. Elle porte sur la fidélité aux décisions initiales de l’équipe, l’explication des choix et la clarté de la synthèse.
Relisez ces critères avant le dépôt : on doit pouvoir comprendre ce qui a été retenu, pourquoi et où retrouver les issues.