Découper une user Story

découper une US

Découper une user story fait partie du TOP 3 des choses les plus importantes à connaître dans le métier de Product owner.

À coté de savoir prioriser et de savoir planifier, le découpage est le 3ème pilier.

D’ailleurs si vous ne savez pas découper une user story, vous aurez beaucoup de mal à la prioriser et la planifier.

En théorie, il existe des dizaines de façon de découper une user story.

Dans ce post, pas de théories bien faites ou de littérature, je vous donne mon avis sur l’art de la découpe dans la vraie vie.

Découper oui, mais pourquoi au fait ?

Imaginez une user story comme ça : Créer une application météo pour iOS.

OK, j’ai grossi le trait mais pourquoi pas…

Sauf que si vous travaillez en Sprint, il va vous falloir un sprint de 18 semaines pour finir cette seule US. 

Le problème c’est que la durée de vos sprint est de 2 semaines.

Dans cet exemple, votre US est un cahier des charges, et l’exécution ne pourra pas se faire en itération.

Oubliez le scrum.

Comment savoir si une US est trop longue ?

US trop longue

Comme vu dans l’exemple ci-dessous, si votre US est trop vague et qu’elle entraîne un développement qui va dépasser la durée de votre sprint, cela va plus ressembler à un cahier des charges.

Du coup, il serait logique de penser qu’une US qui peut être réalisée dans une seule itération est bien découpée.

En résumé :

Avoir comme contrainte la taille de votre sprint pour découper une user story et une bonne méthode pour vous assurer de pouvoir livrer régulièrement.

Il n’y a pas que la taille qui compte

Comme vu dans le précédent paragraphe, on a tendance à penser que découper une user story sert uniquement à réduire la taille. Une fois que l’on a une bonne taille, on est bon !

Sauf que non…

Petit rappel : A quoi sert une user Story ?

Une user story à pour unique but de traduire la réalisation du besoin métier dans le langage du développeur afin qu’il puisse la réaliser.

ATTENTION :
L’US n’a pas pour objectif d’expliquer le besoin métier (Pourquoi ? Pour quoi ? Dans quel but ?…)

Elle doit exprimer COMMENT réaliser ce besoin métier techniquement.

Votre US est destinée uniquement à un développeur. 

  • Ce n’est pas un argument de vente. 
  • Elle se sert pas à convaincre l’utilisateur ou le client de la solution proposée.

À part le développeur et le testeur, personne ne va la lire.

Le client, votre boss, ou n’importe quelle autre personne dans votre entreprise se fiche éperdument de vos US.

Conclusion de mi-parcours :

Quand vous rédigez une US, vous devez vous mettre dans la tête de la personne qui va la développer.

Une US réussie, c’est une US comprise et réalisable par son destinataire.

Le format, le framework utilisé, la longueur ou tout le reste, c’est du bullshit !

Aparté : Ce qui se dit ailleurs…

Si vous lisez des articles sur ce sujet, vous allez tomber sur différentes façons de découper une user story.

Celle qui a le plus le vent en poupe en ce moment c’est le découpage vertical.

Pour faire court, le modèle vertical c’est le modèle qui ne se soucie pas des différentes compétences techniques nécessaires pour réaliser l’US.

L’accent est mis sur la possibilité de livrer de la valeur au client avec une seule US.

Par exemple, avec un découpage vertical, voici le type d’US que vous pouvez avoir :

En tant qu’utilisateur,  je veux pouvoir me connecter en entrant mon adresse e-mail et mon mot de passe.

Ce type d’US englobe le développement Frontend (interface pour se connecter) et backend (appel à la BDD pour renvoyer les bonne infos).

Le modèle horizontal en question…

Le modèle vertical s’oppose au modèle dit horizontal qui lui propose de découper une user story en fonction des compétences techniques pour réaliser un besoin métier.

Évidemment à première vue, le modèle vertical semble plus séduisant.

  • Une seule User story plutôt que plusieurs stories pour réaliser le même besoin
  • Et surtout, l’US est dite indépendante car elle délivre de la valeur utilisateur à elle seule

En clair :  1 besoin métier = 1 user story

Mon (gros) bémol

Je sais qu’il y a des ardents défenseurs de ce modèle parmi les agilistes, consultants et coachs de toute sorte… Un article sur ce sujet, ça fait moderne, réfléchi, pro et puis ça fait des vues et attire de nouveaux clients.

A première vue, le concept est attirant et fait appel au bon sens.

Dans la réalité,  je ne vais pas vous mentir, ce modèle complique plus les choses qu’ils ne les facilitent.

Raison 1

Quand j’entends quelqu’un qui prône le découpage vertical, j’ai l’impression qu’il vit dans un monde où tous les développeurs sont FullStack

  • La réalité est que vous travaillez tour à tour avec des développeurs Mobiles / front / back etc…

Du coup comment on fait dans ce cas là ?

  • On laisse le développeur tout gérer et apprendre un langage Backend ou Frontend à la volée pendant le sprint juste pour réaliser la story ??

Je sais que l’on entend aussi les bienfaits d’être FullStack mais demandez à n’importe quel développeur qui se dit FullStack.  Malgré tout, il aura une appétence pour une certaine technologie.

Par ailleurs, je reviendrai dessus dans un autre post, mais s’entourer de spécialistes est un énorme avantage compétitif comparé à avoir des développeurs touches à tout.  

Raison 2

L’alternative quand on a pas de développeur FullStack et que l’on applique le découpage vertical, c’est d’assigner la même US à plusieurs développeurs.

Rappel :

Une US ne peut être qu’assignée qu’à un seul développeur.

On peut évidemment écrire des sous tâches que l’on rattache à l’US principale.

Le problème en faisant ça, c’est que vous allez bloquer l’US inutilement.

Elle ne peut pas être testée avant d’avoir toutes les tâches techniques terminées.

Raison 3

Une US découpée avec le modèle vertical est une US plus longue réaliser et à tester par nature.

Différentes technologies, ca fait :

  • Plus de scénarios de tests
  • Plus de critères d’acceptance
  • Une US plus longue à lire et à comprendre.

Petit bilan de la découpe vertical.

problème agilité

Comme pour le Framework INVEST que j’avais un peu chahuté dans mon article sur “Comment rédiger une user story”,  ces Frameworks sont vendeurs mais peu pratiques.

Je ne sais pas pourquoi mais certains agilistes sont obsédés par les caractéristiques INVEST.

En voulant à tout pris que les US soient indépendantes et aient de la valeur, ils compromettent leurs tailles et leurs estimations.

Comme je l’ai déjà répété plusieurs fois, une US est destinée à un développeur uniquement (PAS au client).

En ce sens, je privilégie l’intérêt du développeur en faisant attention à ce que l’US soit courte, facilement réalisable et rapidement testable.

Au final, peu importe si elle n’est pas indépendante et ne délivre pas de la valeur.

C’est ce qui me dérange dans le framework INVEST, il mélange des notions utilisateur et des notions développeur.

La valeur et l’indépendance sont des notions utilisateur et votre utilisateur se fiche de vos US, ce n’est pas ça que vous lui livrez.

Ce que vous livrez, c’est le résultat d’un Sprint.
Et donc, c’est le sprint (un ensemble de plusieurs US) qui doit délivrer de la valeur à l’utilisateur.

Ne mélangez pas les choses.

Le mindset pour découper une user Story

Comprenez le workflow de votre équipe

Comprendre les gens

Au risque de choquer certains, découper une user story est plus une histoire de feeling qu’une histoire de technique.

Comme je l’ai lourdement répété plusieurs fois dans ce post, une US est avant tout destinée à un développeur.

Ainsi, il n’existe pas de bon découpage qui s’applique à tous.

Comme pour un marketeur qui rédige une publicité online en fonction du type de prospect, votre découpage doit s’adapter au type de développeur avec qui vous collaborez.

Voici un exemple récent.

Actuellement, je travaille avec 2 équipes de Dev complètement différentes.

L’une dans mon job full-time où je gère une app mobile et l’autre pour un side project pour une app mobile également.

Dans les 2 cas, il y a des parcours utilisateurs à implémenter.

Au niveau Front, chacun de ces parcours représentent environ 5 ou 6 écrans maximum.

Cas 1 :

  • Dans ma 1ère équipe, avant de rédiger les US, j’ai présenté l’UX d’un parcours utilisateur aux développeurs Front.
  • A la suite d’une rapide discussion, ils m’ont dit… 

“Dans les écrans présentés, il y a plusieurs composants différents (calendrier, menu déroulant…)  que l’on va réutiliser ailleurs.  Du coup, plutôt que de faire 1 US par écran, ça serait bien de partir sur une US pour chaque composant puis de faire une US pour assembler tous les composants.  Ca nous permet d’isoler le travail plus facilement”

Cas 2 :

  • Dans ma 2ème équipe, j’ai fait pareil. Avant de rédiger les US, j’ai présenté l’UX d’un parcours utilisateur aux développeurs et comme j’avais déjà validé une méthode avec ma 1ère équipe,  je leur ait dit :  Ça vous dit de faire une US par composant”
  • Voici ce qu’ils m’ont répondu :

“On pourrait faire ça, mais on préfère faire le composant en même temps que l’écran pour affiner le rendu et qu’il s’insère parfaitement.
Du coup, il faut faire 1 US par écran puis faire une US pour assembler tous les écrans.
Comme ça, le testeur pourra tester le composant en situation réelle dans chaque US et l’assemblage sera plus rapide”

  • A votre avis qui à raison ?
  • Quel est le meilleur découpage ?

La vérité…

personne n'a tord

Personne évidemment (ou plutôt tout le monde).

Ce qu’il faut retenir, c’est que ce n’est pas à vous d’imposer le découpage.

En tant que product owner, vous prenez déjà beaucoup de décisions à prendre.

Parlez avec vos devs et laissez leur décider le découpage avec lequel ils sont le plus à l’aise.
Votre job est de leur communiquer un besoin métier et de leur faciliter la tâche pour le réaliser.
Chacun à sa manière de travailler ou de s’organiser. L’important c’est le résultat.

C’est pour ça que je pense que le découpage est surtout une histoire de feeling.

Ça se travaille au cas par cas avec les personnalités avec lesquelles on collabore.

Pour finir

Découper une user story n’est pas si difficile que ça mais c’est un concept très délicat à expliquer.

En toute franchise c’est l’article qui m’a pris le plus de temps à écrire car j’ai eu beaucoup de mal à organiser toutes les idées qui me venaient par la tête.

Ne sous estimez jamais l’importance du découpage.

Un mauvais découpage ça peut 

  • vous plomber vos estimations
  • faire échouer un sprint

Si vous n’avez pas encore ce réflexe, le meilleur conseil que je peux vous donner est qu’avant de foncer pour rédiger de nouvelles US.

  • Parler de la fonctionnalité à développer à votre équipe.
  • Si vous en avez, montrez leurs des UX ou des maquettes
  • Rassembler toutes les compétences techniques autour d’une table

Plutôt que de vous prendre la tête vous-même, il y a de fortes chances que vous trouviez un consensus rapidement pour découper vos US.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *