Menu
Le Product Backlog est le journal de suivi du développement d’un projet. Il regroupe, de manière hiérarchisée, les objectifs à atteindre par chaque membre de l’équipe pour réaliser les User Stories demandées par le Product Owner.
En tant que tel, il est la clé de voûte sur laquelle repose l’intégralité des évolutions du projet : il faut donc qu’il soit élaboré avec un grand soin. À travers nos explications et nos exemples, cet article vous permettra de mieux comprendre les enjeux de cet outil agile incontournable.
Le Backlog est géré par le Scrum Master. C’est à lui d’interpréter les User Stories pour en tirer les éléments à développer.
Par exemple, sur notre application qui peut trier les œuvres d’art des musées en accédant à leur catalogue, prenons l’User Story : “L’utilisateur veut connaître les musées qui proposent des collections temporaires dans un rayon de 5 kms pour obtenir des informations”.
Il faut commencer par établir les fonctionnalités nécessaires pour réaliser ce scénario :
Cette liste n’est pas exhaustive, mais permet de bien cerner les différents aspects du développement de cette User Story en particulier.
En plus des fonctionnalités, il faut prendre en compte l’acquisition de connaissances.
C’est une étape de recherche de la part de l’équipe de développement. Dans notre exemple, cela pourrait être une étape de renseignement sur l’accessibilité des informations relatives aux collections permanentes ou temporaires des musées : où se trouve cette information, et comment la récupérer de manière automatique ? À quelle fréquence faut-il actualiser cette prise d’information ?
Le Backlog est également l’endroit où se décide la hiérarchisation des étapes de développement. Quelle User Story est la plus importante à développer ?
Les tâches essentielles sont généralement les plus complexes. Il y a ici un piège dans lequel il faut prendre garde de ne pas tomber : de manière naturelle, les équipes vont souvent vouloir atteindre un objectif le plus vite possible. Il arrive donc que les tâches moins complexes soient effectuées en premier, bien qu’elles soient moins prioritaires. Il appartient au Scrum Master de canaliser les efforts de son équipe dans le bon sens.
Il est primordial de communiquer entre collègues pour établir l’urgence des tâches, mais également leur complexité. Le temps est généralement le facteur le plus restrictif dans les projets réalisés avec la méthode Scrum, et il faut l’utiliser à bon escient.
Apprenez en plus sur la communication en équipe en cliquant sur ce lien.
Une fois le premier sprint réalisé, le Product Owner va faire des retours sur le rendu précédent. Deux éléments vont donc s’ajouter aux fonctionnalités et à l’acquisition de connaissances déjà présentes dans le Backlog :
Il faut ajouter à cela les éléments de correction de fonctionnalités que le Product Owner veut voir. Pour notre application, cela peut-être que finalement, il ne faut pas se baser sur la localisation de l’utilisateur, mais sur un point d’intérêt spécifique comme l’Office du Tourisme de la ville recherchée.
En plus des fonctionnalités, il faut prendre en compte l’acquisition de connaissances.
C’est une étape de recherche de la part de l’équipe de développement. Dans notre exemple, cela pourrait être une étape de renseignement sur l’accessibilité des informations relatives aux collections permanentes ou temporaires des musées : où se trouve cette information, et comment la récupérer de manière automatique ? À quelle fréquence faut-il actualiser cette prise d’information ?
