Sprint Backlog / Sprint planning

La présente page vous guide dans l’utilisation de votre document Excel intitulé « Sprint Backlog ».

Si vous n’êtes pas encore membre, découvrez notre kit de l’agilité. Ne manquez pas l’opportunité de l’acquérir et de profiter de tous les avantages qu’il peut apporter à votre gestion de projet agile.

Objectif du livrable

Le support du Sprint Backlog permet de centraliser le périmètre du Sprint et lister toutes les Users Stories à développer et les tâches à réaliser pour atteindre l‘objectif du Sprint et créer un incrément du produit.

Le Sprint Backlog est mis à jour très régulièrement par l’équipe, il représente un planning détaillé de l’équipe. 

La mise à jour du Sprint Backlog ne devrait pas étendre le périmètre du Sprint mais le décomposer en tâches facilement réalisable par l’équipe et permettant de mesurer facilement l’avancement du produit.

Déblocage des macros

Avant d’ouvrir un fichier Excel, pensez à débloquer les macros.

Pour ce faire, faites un clic droit sur le fichier avant de l’ouvrir. Ensuite choisissez Propriétés, puis activez la case à cocher Débloquer sous l’onglet Général.

Ceci afin d’éviter d’avoir un message rouge à l’ouverture d’un fichier Excel :

Activation des macros

Pour s’assurer du bon fonctionnement du template, vérifiez que les macros sont activées :

Quand utiliser ce livrable ?

Le Sprint Backlog est utilisé lors de la phase d’exécution durant le Sprint.

Comment utiliser ce livrable ?

Durant le Sprint Planning

1. Lors de la cérémonie de Sprint Planning, le Sprint Backlog est constitué en intégrant les éléments du Backlog Produit sélectionnés pour ce Sprints. 
2. Ces éléments peuvent être décomposés en plusieurs tâches selon l’appréciation de l’équipe

Déroulement du Sprint Planning :

• Le PO présente à l’équipe les USs priorisées pour ce Sprint en les expliquant dans le détail les fonctionnalités du produit
• Les membres de l’équipe de Développement échange avec le PO afin de clarifier les fonctionnalités et vérifier que les prérequis de la DoR ( Definition Of Ready) sont bien respectés
• L’équipe de développement décompose davantage les USs si nécessaire
• L’équipe de développement estiment les USs (par exemple selon la technique du Poker Planning)
• La validation du périmètre final du Sprint se fait en prenant en considération la capacité ou la vélocité de l’équipe. Dans certains cas, le périmètre de Sprint peut s’étaler au delà de la capacité de l’équipe afin de s’assurer que l’équipe pourra suffisamment être alimentée durant le Sprint
• Le PO définit un objectif du Sprint 
• Le Sprint Backlog est défini
• Le Sprint peut démarrer

Durant le Sprint ou l’itération

1. Lors du daily meeting, l’équipe utilise le Sprint Backlog pour identifier sur quoi avancer le jour même
2. A chaque changement de statut d’une User Story ou tâche, le statut d’avancement doit être mis à jour 

Structure du document

1. Format liste détaillée :

• N° du Sprint
• Objectif du Sprint
• Nom du produit
• Date de dernière mise à jour
• Num de l’item : Cette colonne permet de spécifier le type d’élément présent dans le sprint backlog, comme une user story, une tâche, un bug, etc. Cela permet de classer et d’identifier clairement chaque élément en fonction de sa nature.
• Epic parent : Cette colonne permet de lier l’élément du sprint backlog à un epic parent, s’il en existe un. Il s’agit de l’élément de plus haut niveau auquel l’élément du sprint backlog est associé, fournissant une meilleure compréhension de son contexte.
• Titre de l’item : Cette colonne contient le titre ou le nom de l’élément du sprint backlog. Il s’agit d’une description concise et précise qui permet d’identifier clairement l’élément.
• Description de l’item : Cette colonne offre une description détaillée de l’élément du sprint backlog. Elle fournit des informations supplémentaires sur les fonctionnalités, les exigences ou les spécifications de l’élément afin de faciliter sa réalisation.
• Valeur business : Cette colonne évalue la valeur commerciale ou stratégique de l’élément du sprint backlog. Elle permet de prioriser les éléments en fonction de leur contribution aux objectifs globaux du projet ou de l’entreprise. Un exemple de la valeur business peut être : “L’amélioration de l’expérience utilisateur lors du processus de paiement en ligne”. Cela signifie que l’élément du sprint backlog lié à cette valeur aura pour objectif de résoudre les problèmes ou les frictions rencontrés par les utilisateurs lorsqu’ils effectuent des paiements en ligne.
• Priorité : Cette colonne indique la priorité de l’élément du sprint backlog par rapport aux autres éléments. Elle permet de définir l’ordre dans lequel les éléments seront abordés et réalisés pendant le sprint.
• Charge en story point : Cette colonne représente l’estimation de l’effort nécessaire pour réaliser l’élément du sprint backlog en utilisant l’échelle des story points. Cela permet d’évaluer la complexité ou la quantité de travail associée à l’élément.
• Statut : Cette colonne permet de suivre l’avancement de chaque élément du sprint backlog. Elle indique si l’élément est « À faire », « En cours », « Terminé » ou tout autre statut pertinent pour le suivi du sprint.

2. Format KANBAN

Ce format est utilisé pour afficher visuellement l’avancement des travaux des USs planifié dans le Sprint Backlog.

Le Board comprend 7 colonnes :

• To Do : Liste des USs planifiées dans le Sprint
• In Dev : Liste des USs en cours de développement par l’équipe de développement
• In testing : Liste des USs en cours de développement par l’équipe de développement. cette étape est séparé de la colonne “In dev” si des rôles spécifique déroulent les tests ou si c’est justifié de séparer l’activité de développement d’un type de tests techniques particuliers
• In technical Review : Liste des US à valider techniquement par le Tech Lead ou un des développeurs
• Blocked  / Waiting for information : Liste des USs bloquées ou en attente d’information en rapport avec des parties prenantes externes. Ce statut ne peut pas être utilisé pour des sujets internes à l’équipe parce que le mode de fonctionnement Agile désamorce les blocages et les échanges d’information au sein d’une équipe
• In functional review : Liste des USs en attente de validation fonctionnelle par le PO et le B A
• Done : Liste des USs finalisées ayant implémentés une fonctionnalité apportant de la valeur au produit

En savoir plus

Pour en savoir plus sur le Sprint Planning, consultez le lien de cet article.