Backlog produit, du thème aux user-stories !

Je vous propose de voir ensemble comment bien gérer son backlog du thème aux user-stories. Ce n’est pas compliqué en effet, mais cela pourra aider ceux qui font leurs premiers projets Agiles.

Vous pouvez regarder la vidéo de la minute agile sur le backlog :

Un backlog produit par produit

Dans la majorité des cas, on va créer un backlog produit par produit. On va considérer que c’est le découpage le plus haut du produit.

Au passage sur les gros produits où il est indispensable de travailler avec plusieurs équipes, l’équipe se partagera le même backlog. C’est ce qu’on appelle faire de l’agile à l’échelle.

Cependant dans certains cas, les équipes qui gèrent X produits vont privilégier d’avoir un backlog complet pour l’ensemble de leurs tâches mais on va considérer cela comme un cas particulier car il n’est jamais bon d’intervenir sur plusieurs produits dans un seul sprint.

Pour notre article, je vais partir sur la création d’un site ecommerce imaginaire « Myshop Partner ». La construction de ce site ecommerce passera par un backlog à part entière.

Un Sprint backlog par Sprint

Le Sprint backlog représente le contenu du travail à réaliser au sein d’un Sprint. Si nous avons plusieurs équipes qui travaillent sur un même backlog, on pourra avoir plusieurs sprint en parallèle.

Un sprint backlog ne dure que le temps d’un sprint et sera remplacé par un autre sprint backlog. C’est le Product Owner qui proposera le contenu d’un sprint backlog au début du sprint que l’équipe devra développer.

* On parlera de Product Owner dans cet article car c’est le rôle le plus connu pour la gestion backlog avec le Scrum mais il est possible que ce rôle soit tenu par d’autres rôles comme le représentant du client.

Un backlog se découpe en thèmes

Afin de faciliter le travail de priorisation, on va réaliser un premier découpage du backlog en plusieurs thèmes.

Il n’est pas facile de définir une règle stricte de ce qu’est un thème car cela dépendra de l’interprétation de chacun des Product Owner (PO). Le principal c’est que le PO se sente à l’aise avec les thèmes qu’il a définie et qu’ils vont lui permettre de bien prioriser au niveau le plus haut.

Par exemple pour notre site ecommerce, nous pourrions avoir :

• thème 1 : un panier
• un thème 2 : la gestion des produits
• thème 3 : la navigation du site

Backlog produit : thèmes découpés en Features

C’est moins courant mais certains ajoutent un découpage supplémentaire : celui des features (des fonctionnalités). Cela peut-être utile pour gérer un autre niveau de priorisation.

Par exemple pour notre site ecommerce, nous pourrions avoir :

• feature 1 : page panier
• une feature 2 : moyen de paiement
• feature 3 : gestion de la livraison

Backlog produit : features découpées en User-stories

Les features peuvent être découpées en Epics. Cependant les Epics ne sont pas le groupement de user-stories comme le pensent certains. Allez voir l’article sur le sujet que j’ai écrit pour mieux comprendre ce qu’est un Epic.

Article : Qu’est-ce vraiment un Epic en Agile ?

Pour faire simple, un Epic va devenir 1 ou x user-stories.

On va donc considérer que les features sont découpées en user-stories (Epics affinés) comme le représente le dessin ci-dessous.

Par exemple pour notre site ecommerce, nous pourrions avoir pour la feature 2 nommée « moyen de paiement » :

• user-story 4 : En tant que client, je souhaite payer mon panier en carte bleue
• une user-story 5 : En tant que client, je souhaite pouvoir payer mon achat en 3 fois
• user-story 6 : En tant que client, je souhaite pouvoir payer en virement bancaire

Si j’ai vulgariser les user-stories pour que le découpage soit bien compris, dans la vraie vie, il aurait été probable de devoir aller plus dans le détail pour ces user-stories.

Backlog produit : user-stories découpées en sous-tâche techniques

En Scrum, les développeurs découpent l’ensemble des user-stories en sous-tâches techniques afin de s’aider dans leur travail. Le niveau de détail des sous-tâches techniques est défini par les développeurs eux-mêmes : ils n’y a pas de mauvais découpages ou de bons découpages.

Par exemple pour notre site ecommerce, nous pourrions avoir pour la user-story 4 nommée « En tant que client, je souhaite payer mon panier en carte bleue » :

• sous-tâche technique 1 : contacter API bancaire
• une sous-tâche technique 2 : créer connexion sécurisée avec OAUTH
• sous-tâche technique 3 : afficher moyen de paiement

Un thème pouvant définir quelque chose de technique

Dans des framework comme SAFe, on parle d’Enablers à différents niveaux pour définir l’architecture, de l’exploration, de l’infrastructure ou de la conformité. Voici un article qui parle en quelques mots de ce framework.

Article : Qu’est-ce que le framework SAFe 4.5 ?

Cependant dans cet article, on ne parlera pas de SAFe qui impose une façon de faire qui est intéressante de connaitre mais qui n’est pas forcément adaptée à tous les contextes.

Cette partie de l’article est une vision qui n’est pas partagée par l’ensemble des coachs agiles. Certains estiment que tout doit passer par des user-stories ; pour ma part, j’estime que ce n’est pas le cas. Ne soyez pas surpris un jour de voir d’autres explications qui iront en contradiction avec cette partie de l’article.

On va donc autoriser d’avoir des tâches techniques au même niveau que des user-stories pour définir des travaux techniques. Exemple : installation d’une base de données (utilisée probablement par 80% des user-stories).

Voici un article qui parle justement des tâches techniques voire des Spike qui est aussi une notion différente des user-stories :

Articles :

Les Nonfunctional Requirements (NFR) en Scrum ?
Qu’est-ce qu’un Spike dans un projet Scrum ?

Il est possible également de définir un thème comme quelque chose de technique comme « refactoring en angular 5 ». Cela se découpera en plusieurs tâches techniques voire par fonctionnalités si le Product Owner se sent plus à l’aise comme cela.

Les développeurs pourront sans soucis découper leurs tâches techniques en sous-tâches techniques lors du Sprint planning. Le contenu des tâches techniques sera de la responsabilité des développeurs et non du Product Owner contrairement aux user-stories.

Conclusion backlog produit

Voici l’exemple le plus courant de découpage de backlog produit que l’on rencontre (les features sont moins utilisées comme intermédiaire). Utiliser ces termes permet souvent d’avoir un langage proche des autres équipes agiles et de mieux se comprendre entre équipes.