Lors de notre dernière rétrospective, les équipes Ginger et Lemon qui développent notre application DR2 ont souhaité réfléchir à comment faire pour améliorer le fonctionnement de nos séances de conception. Pendant ce rituel, qui a lieu tous les vendredis, les développeurs, le product manager et les parties prenantes se réunissent pendant une heure pour échanger et chiffrer le travail à faire. Sur le papier, rien de plus simple ! Pourtant, l’équipe a identifié deux écueils :

  1. Le contenu. Quelle doit être la nature de notre conversation ? S’agit-il de s’aligner sur le besoin fonctionnel et/ou de s’accorder sur les choix d’implémentation technique ?
  2. L’objectif. A quoi doit nous conduire cet échange ? Préciser le besoin ? S’assurer que l’expression de besoin soit “prête” ? Chiffrer le travail à réaliser ?

Il m’a semblé intéressant d’essayer de poursuivre les réflexions entamées en rétrospective à travers ces quelques lignes. Dans un premier temps j’aimerais revenir sur ce que dit la littérature en faisant un petit tour du coté du Scrum Guide pour savoir ce qui est dit à propos de la conception. Puis nous verrons comment faire pour s’assurer d’avoir des User Stories prêtes à l’aide de deux outils : les 6D et l’exemple mapping.

Loin de moi l’idée d’imposer une solution mais plutôt de prendre un peu de recul et de susciter les échanges en commentaires de cet article. Bonne lecture en attendant vos feedbacks !

L’affinage de Backlog : “Oh le con ! Mais il est pas fini d’affiner !” (Karadoc dans Kaamelott)

Commençons par un peu de vocabulaire. Le Scrum Guide aborde ces questions liées à la conception à travers le rituel du backlog refinement. Ce terme, que l’on peut traduire en français par affinement de backlog, a remplacé celui de grooming depuis 2013 :

Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit.

L’affinement du Product Backlog consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s’agit d’une activité continue visant à ajouter des détails, tels qu’une description, un ordre et une taille. Le Product Owner peut influencer les Developers en clarifiant ses explications et les aider à trouver des compromis.

Scrum Guide 2020

Le risque lorsque l’on fait du développement logiciel, c’est de commencer à travailler à partir d’un besoin utilisateur (on parle de user story) que l’équipe comprend mal ou qui n’a pas fait l’objet d’un travail de découpage. Bref une demande pas prête parce que mal affinée. L’affinage consiste donc à réduire les risques en amont du développement en construisant un équilibre subtil entre définir le besoin dans ses moindre détails (document de spécifications illisibles) et ne rien définir (pas besoin, on sait faire).

Cet affinage se fait tous les vendredis pendant une heure à travers une discussion entre l’équipe de développement et le produit. Au cours de cet échange, on aborde systématiquement les points suivants :

  1. Explication du contexte commercial, du problème rencontré et de pourquoi est ce que l’équipe doit travailler sur ce sujet. Le Product Owner présente les nouveaux récits utilisateurs : le QUOI ! A travers une conversation, il aide l’équipe à comprendre le problème, à préciser le besoin et à s’approprier le produit.

  2. Définition de la faisabilité. De son coté, à partir du besoin exprimé, l’équipe réfléchit au COMMENT est ce qu’on peut résoudre ce problème ? Elle regarde si on peut découper et/ou ordonner le travail à faire en le décortiquant et le détaillant. Attention, il ne s’agit pas de partir dans des digressions techniques au risque de perdre les parties prenantes mais bien de procéder à un découpage fonctionnel du besoin. Parfois à travers la discussion et la confrontation d’idées, on se rend compte que le besoin nécessite d’être affiné davantage : il manque du contexte, des maquettes, des règles métier… Ce n’est pas grave si ce n’est pas “prêt” ! On se revoit la semaine d’après avec de nouveaux éléments.

  3. Estimation du travail à faire. A travers la conversation, l’équipe prend conscience de l’effort à produire pour construire un incrément du produit et peut répondre à la question COMBIEN en chiffrant le besoin. Déterminer la taille des user story ne constitue donc pas une fin en soi mais une simple étape de l’affinement de backlog.

On le voit, l’affinage de backlog est un moment privilégié pendant lequel l’équipe échange avec le produit pour pouvoir s’aligner sur le besoin, s’assurer de la faisabilité de la demande et vérifier que cette dernière est réellement prête à être développée.

Comment produire des Users Stories prêtes au bon moment ?

Si on entre dans une séance d’affinage de backlog avec une liste à jour des demandes produit, il est important de bien quantifier le nombre de ces demandes. Pas assez de demandes et l’équipe n’a plus rien à développer. Trop de demandes et le contexte technique / métier / commercial peut remettre en question ce qui avait été décidé. On s’appuie donc sur la capacité de production de l’équipe (sa vélocité) mesurée lors des itérations précédentes pour quantifier le nombre d’éléments qui doivent être prêts dans le backlog. Mais comment procéder pour s’assurer que les demandes produit soient réellement prêtes ?

Mieux que la 3D, les 6D !

Pour répondre à cette question on utilise la Definition of Ready (la DoR). C’est un ensemble de critères qui déterminent si une User Story est prête à être traitée par l’équipe de développement. Christophe Aubry en parle très bien dans son ouvrage SCRUM, pour une pratique vivante de l’agilité. Selon lui, pour être prête, une user story doit donc être :

  • désirable : elle doit apporter de la valeur à l’utilisateur.
  • décomposée : elle doit être suffisamment petite.
  • débattue : elle doit avoir fait l’objet d’une conversation avec le PO pour que l’ensemble de l’équipe soit alignée sur la demande.
  • démontrable : on pourra montrer aux parties prenantes le développement réalisé.
  • définition de fini (DOD) : on sait à quelles conditions elle sera terminée, on a bien identifié le périmètre de la demande.
  • dérisquée : on a parlé ensemble des éventuels effets de bords pour réduire le risque.

On peut utiliser cette DoR sous forme de checklist que l’équipe consulte lors de l’affinage de backlog pour s’assurer qu’une user story est véritablement “prête”. Simple non ? Et pourtant il arrive parfois que la simple énumération de ces critères ne soit pas suffisante. Heureusement il existe un atelier qui permet de s’assurer que ces user stories sont réellement prêtes !

L’exemple mapping ou l’art d’utiliser les post-it

L'exemple mapping, une histoire de post-it

Malgré tous vos efforts le besoin exprimé est toujours flou, vous n’arrivez pas à identifier des critères d’acceptance, la tâche vous semble toujours trop grosse ? L’exemple mapping est un atelier qui doit vous permettre de surmonter toutes ces difficultés et de s’assurer que votre US est réellement “prête”. L’article de Cucumber explique très bien comment organiser cet atelier. Pour cela, il vous suffit de réunir l’équipe de développement et les parties prenantes autour de quelques post-its de 4 couleurs différentes (pour les équipes en remote, vous pouvez utiliser un board virtuel). L’objectif est donc, à partir d’une expression de besoin, de construire une carte sur 3 niveaux :

  1. La User Story : le PO choisit une US, l’écrit sur un post-it jaune et exprime le besoin.
  2. Les régles : l’équipe échange sur les règles qui corresponde à cette US.
  3. Les exemples : à travers un échange on construit les exemples qui constitueront autant de tests à implémenter par la suite.

En visualisant pour chaque user story les règles qui lui sont associées ainsi que les exemples concrets on s’assure de dérisquer le travail à faire ! Si au cours de votre échange, la carte devient trop grande pour tenir sur votre table c’est surement qu’il faut redécouper le besoin !

Conclusion

Revenir à la source permet souvent de retrouver son chemin. Relire le Scrum Guide m’a permis d’y voir plus clair sur les attendus de l’affinage de backlog. Cependant, il nous reste encore du chemin à faire pour faire en sorte que nos users stories répondent véritablement à l’ensemble des critères évoqués ci-dessus. J’ai essayé d’esquisser quelques pistes pour nous aider, nous améliorer et construire ensemble le meilleur produit possible.