« Tout est une question d’arriéré de produit (Product Backlog). Le Product Owner doit le gérer. Donnez-lui la priorité. Remplissez-le de User Stories. »

Backlog is not a Linear List par Zuzi Sochova

https://agile-scrum.com/2025/03/30/backlog-is-not-a-linear-list/

Cela vous semble familier ? À certains stades de la transformation agile, il est typique de se concentrer sur la construction d’un arriéré ou backlog de produit. Et d’utiliser Jira pour cela. Vous trouverez de telles listes linéaires de tâches dans presque toutes les organisations au début de leur parcours agile. Et bien que le Product Backlog soit un outil très important car il apporte de la clarté et aligne les gens autour des mêmes objectifs business, c’est aussi l’un des outils les plus mal compris et les plus mal utilisés.

Cela part souvent par une bonne intention, le Product Owner demandant aux clients ce qu’ils veulent. Et ils réfléchissent à toutes les fonctionnalités possibles que vous pouvez imaginer, dans une bonne intention. Et le backlog/contenu ne cesse de croître alors que les attentes en matière de délais restent les mêmes. C’est le début très fréquent d’une grande déception avec Agile.

« Cela ne nous a pas aidés. Ce n’est pas plus rapide ! » disent les gens, et ils ont raison.

L’agilité n’est pas le moyen de fournir plus de fonctionnalités plus rapidement. Bien au contraire. C’est un moyen d’obtenir plus rapidement une valeur business plus élevée, et ce sont là deux choses différentes.

Donc, si vous voulez obtenir plus de valeur business, commencez par le backlog.

Mais cette fois-ci, vous ne demandez pas ce que vous voulez mettre en œuvre, mais plutôt les besoins et recherchez une fonctionnalité minimale à mettre en œuvre pour satisfaire ces besoins. 80 % de la valeur réside dans 20 % de la fonctionnalité et c’est exactement ce qu’un bon Product Backlog doit identifier. Les objets de plus grande valeur en premier, le reste plus tard ou jamais.

Un bon Product Backlog est co-créé en collaboration avec le client, les parties prenantes et les membres de l’équipe. Ils doivent tous découvrir les besoins de l’entreprise. Ils doivent tous développer une empathie pour les clients. Dans la plupart des cas, le Product Backlog qu’ils créent ensemble n’est pas une liste linéaire qui s’adapterait à des outils traditionnels comme Jira ou Excel, mais très souvent, nous utilisons la technique du Story Mapping pour créer des cartes multidimensionnelles, ou la technique de cartographie d’impact pour créer une carte mentale, ou visualiser le produit sous forme d’arbre et élaguer les branches. Rien qui ressemblerait à une liste linéaire de choses à faire.

Toutes les techniques ont une chose en commun ; Elles se concentrent sur la valeur commerciale et les besoins du client. Elles ne décrivent pas la solution.

Le comment dans Scrum doit être découvert lors du Sprint en collaboration d’équipe. Alors :

Oubliez les exigences, arrêtez de demander à vos clients ce qu’ils veulent, et concentrez-vous plutôt sur la découverte de leurs besoins et visualisez ensemble la valeur dans votre Product Backlog.