Gestion des backlog, 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.

Un backlog par produit

Dans la majorité des cas, on va créer un backlog 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.

sprint backlog
sprint backlog

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.

themes agile
themes agile

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
  • thème 2 : la gestion des produits
  • thème 3 : la navigation du site

Des thèmes peuvent être 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.

Découpage backlog en features
Découpage backlog en features

Par exemple pour notre site ecommerce, nous pourrions avoir :

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

Des features peuvent être 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.

Les epics deviennent des user-stories
Les epics deviennent des 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.

Découpage du backlog en user-stories
Découpage du backlog en user-stories

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
  • 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.

Des user-stories peuvent être 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.

Découpage en sous-taches techniques
Découpage en sous-tâches techniques

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
  • 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).

Tâches techniques
Tâches techniques

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

Voici l’exemple le plus courant de découpage de backlog 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.

2 Replies to “Gestion des backlog, du thème aux user-stories !”

  1. Bonjour et merci. C’est super clair!
    J’ai une question concernant l’ux/ui design & l’agile : avez vous rencontrer des cas de backlog intégrant ces deux notions ux/ui ?
    Si oui, auriez-vous quelques exemples ou pistes sur le sujet à partager ?

    1. Hello Vincent,

      En effet l’UX/UI s’intègre dans la construction du backlog tout au long du projet en aidant le PO sur la partie UX et en partageant wireframe voire IHM quand la user-story est prête à être prise en charge par les développeurs. Je prévois de faire un article prochainement sur le sujet 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *