Le backlog de sprint est l’ensemble des éléments du backlog produit sélectionnés pour un sprint, accompagnés du plan permettant de les réaliser. Contrairement au backlog produit, il appartient aux développeurs eux-mêmes.
Cette propriété n’est pas un détail d’organisation. Le Product Owner décide de ce qui est prioritaire ; l’équipe décide de ce qu’elle est capable d’emporter dans le sprint et de la manière dont elle s’y prendra. Confondre les deux revient à réintroduire une planification descendante sous un vocabulaire agile.
Trois composantes indissociables
Le backlog de sprint réunit l’objectif du sprint, les éléments sélectionnés et le plan de réalisation. L’objectif donne le sens, les éléments donnent le périmètre, le plan donne la manière. Réduit à une simple liste de tickets, sans objectif ni plan, il perd l’essentiel de son utilité.
Le plan est délibérément le moins formel des trois. Il prend souvent la forme de tâches attachées à chaque élément, mais rien n’impose ce découpage : ce qui compte est que l’équipe sache, chaque matin, où elle en est par rapport à l’objectif qu’elle s’est fixé.
Un document vivant, pas un engagement gravé
Le backlog de sprint évolue tout au long du sprint. Découvrir une tâche oubliée, en supprimer une devenue inutile, réviser une estimation : ces ajustements sont normaux et attendus. Ce qui ne change pas, c’est l’objectif du sprint.
La mêlée quotidienne sert précisément à cette mise à jour. Elle n’est pas un rapport d’avancement destiné au management mais un moment de replanification entre pairs. Le Scrum Guide insiste sur ce point, régulièrement dévoyé en réunion de contrôle où chacun justifie sa journée.
Un signe de dérive est facile à repérer : lorsque le backlog de sprint est renseigné par une seule personne après coup, pour la forme, il ne sert plus à piloter le travail mais à documenter ce qui a déjà eu lieu. L’outil devient alors une charge administrative sans contrepartie.