En agile, une User Story (US) est une courte expression écrite du besoin. A l’inverse des spécifications très détaillées des projets informatiques traditionnels, l’US doit servir de support pour ouvrir à des discussions orales :
Comme l’écrit Mike Cohn (l’un des contributeurs au développement de la méthodologie Scrum) :
“User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.”
“ Les Users Stories font partie de l’approche agile et aident à déplacer le focus de la rédaction du besoin vers l’expression orale de ceux-ci. Toutes les User Stories agiles incluent une ou deux phrase écrites et, le plus important, une série de discussion sur les fonctionnalités attendues.”
https://www.mountaingoatsoftware.com/agile/user-stories
Pourtant dans la plupart des projets sur lesquels j’ai travaillé, nous avons souvent été confrontés au besoin d’aller plus loin dans la rédaction d’US.
Nous en sommes arrivés à construire un modèle bien plus détaillé. Un modèle écrit, conçu pour favoriser l'expression orale. Il s'est avéré utile dans des contextes où la communication orale n'était pas fluide.
Voici donc ci-dessous le modèle détaillé. Je vais vous expliquer par la suite à quel moment il peut fonctionner et à quel moment s’en détacher. L’important étant de toujours garder du recul vis-à-vis de ce qui est présenté ici et de maintenir la communication orale comme mode de fonctionnement principal au sein de votre équipe.
???? Numéro de l’US : US n°1
???? Titre : Pouvoir rédiger une US de qualité
???? Description :
En tant que personne en charge de rédiger une User Story (US)
Je souhaite trouver dans cet article toutes les informations utiles à la rédaction d’une US
Afin de prendre du recul sur ma façon de travailler et trouver des tips pour de prochaines US
----
???? Contexte
Cas 1 : Vous vous lancez dans un projet agile et vous allez créer des US mais vous ne l’avez jamais fait jusque-là.
Cas 2 : Vous travaillez déjà avec des US mais avez besoin d’essayer un nouveau modèle pour fluidifier le travail en équipe
???? Attendu
Être en mesure de créer une US adaptée au besoin de l’équipe et du projet, à partir des tips présentés ici.
???? Visuel(s) de l’attendu
???? Critères d’acceptance
L’US est validée si :
Lorsque nous regardons ce modèle nous pouvons penser qu’il ne correspond pas au modèle agile traditionnel. Au lieu d’écrire un ticket pour ouvrir à la discussion, nous inscrivons suffisamment de détail pour que le ticket soit auto-portant.
Bien que certains pourraient l’associer à des spécifications (utilisées dans les projets en cycle en V), il faut comprendre que la démarche pour le construire est opposée. En cela ce n’est ni une “spécification courte”, ni une “US longue” mais finalement une “US hybride”.
En effet, le ticket est complété suite aux discussions orales entre les personnes de l’équipe (le PO, le/les dev, les UX, les experts, etc.) et non l’inverse.
Il représente la vision de l’équipe sur le sujet et non pas uniquement celle du responsable métier.
A chaque étape de la construction de la vision (cadrage, présentation en planning poker, échanges avec le développeur qui va traiter le sujet, ajout de détails pendant le développement, etc.) le ticket s’enrichit. En clair, le ticket se détaille au fur et à mesure que les conversations avancent.
Pour certains cela peut sembler absurde d’écrire après une conversation...
Et pourtant dans certains cas cette démarche est très utile. Ce modèle d’US peut servir de filet de sécurité pour des personnes et des équipes encore peu à l’aise en agile. Je vais donc vous raconter pourquoi il a vu le jour et dans quelles conditions je l’utilise.
Ce modèle a émergé sur un très gros projet de refonte d’un site institutionnel. Nous étions dans une grande équipe et le rôle de product owner se trouvait partagé entre plusieurs personnes.
Composition de l’équipe :
11 développeurs et développeuses, 1 intégrateur HTML, 2 experts en accessibilité, une UX, de 1 à 4 PO selon les moments, un delivery manager, un chef de projet, etc.
Il était difficile d’avoir un échange fluide et spontané avec tout le monde et il était compliqué de constamment partager le même niveau d’information.
Comme vous pouvez l’imaginer sur un projet impliquant autant de monde, les personnes n’étaient pas toujours disponibles en même temps et nous ne pouvions pas cadrer avec toute l’équipe*. Il était très difficile de se coordonner. Nous ne possédions donc pas tous le même niveau d’information sur les sujets.
*Equipe = toutes les personnes impliquées sur le projet au quotidien (développeurs, PO, UX, etc.)
Pour cette raison nous avons mis en place un processus itératif de construction de la vision. Au cours de ce processus tout le monde pouvait, à un moment ou un autre, participer à cette construction :
1- Toute l’équipe connaît et (dans l’idéal) contribue à la construction de la vision globale.
2- A partir du modèle des 3 amigos découpage des fonctionnalités et discussion sur le contenu de chaque partie.
3- Création des US liées au découpage, priorisation et rédaction des US prévues dans les prochains sprints (pas plus de 2 ou 3 sprints à l’avance pour éviter l’obsolescence du ticket). Le PO rédige à partir des éléments qui sont ressortis lors des échanges précédents.
4- Relecture par un développeur pour vérifier la cohérence technique et complétion ou modification si besoin.
Important : pour rappel, le PO n’expose que le besoin et non pas la façon dont ce besoin doit être développé.
5- Présentation en planning poker des US à venir pour le développement. Ce point permet à toute l’équipe d’échanger sur la façon dont elle imagine le développement de la fonctionnalité, qu’elle éclaircisse les points flous en posant des questions et qu’elle évalue le ticket à partir de l’hypothèse technique élaborée en groupe. C’est aussi un moment où retoquer une US est possible (si elle manque d’éléments structurants pour avancer, si des questions importantes et sans réponses se posent, etc.).
6- Le ticket peut ensuite partir en développement_._
Pendant tout le développement les développeurs et les PO échangent ensemble. Directement pendant le développement mais également pendant les étapes suivantes (revue de code et test par le PO).
Nous avons choisi cette façon de travailler car il nous était impossible de travailler tous ensemble tout le temps. Pour autant le risque d’un tel processus est que l’information se perde.
C’est pour cette raison que nous avons décidé de mettre par écrit tous les résultats de nos conversations.
L’US s’étoffait donc de façon itérative, à chaque étape du processus présenté ci-dessus.
Pour maintenir la communication orale malgré le contexte, nous avions également instauré des rituels d’échange (un stand up général puis un stand up fonctionnel, ateliers de cadrage avec présence des différents rôles, définition commune de ce qui est considéré comme “ fini ” (DOD) dans laquelle nous avions automatisé la relecture des US par différents rôles concernés, etc.).
L’enjeu était de construire et partager la vision du produit collectivement. Nous y avons donc remédié en la construisant de façon orale et incrémentale et en retranscrivant cette vision dans le ticket. Cela nous a ainsi permis de pallier aux éventuels manques de communication que nous pouvions malgré nous rencontrer, du fait de la grande taille de l’équipe.
L’autre intérêt de compléter le ticket après une discussion est de laisser une trace pour les futures personnes qui travailleront sur le sujet.
C’était un gros projet qui allait durer plusieurs années. Nous savions qu’avec beaucoup de prestataires, l’équipe changerait plusieurs fois. Et le jour où des personnes auraient besoin de se repencher sur un des sujets que nous avions travaillé, elles seraient en mesure d’y trouver des éléments intéressants :
Ce modèle d’US permet donc de retrouver beaucoup d’informations sur ce qu’il s’est passé à un moment T. Ce peut être utile lorsque des personnes travaillent à nouveau sur un sujet et ont besoin d’éléments sur la façon dont avait été structuré et compris le besoin.
Comme je l’ai mentionné plus haut, nous étions plusieurs product owners (PO).
Le projet étant long et fonctionnant bien, plusieurs personnes ont pu profiter du contexte pour monter en compétence sur le rôle de PO. Les profils étaient variés : du stagiaire à la personne interne experte dans le métier, à qui on propose de prendre le rôle.
Le modèle présenté ci-dessus a servi de cadre pour intégrer facilement les débutants à l’équipe.
Il permet d'acquérir les bons réflexes pour construire et partager la vision du produit (savoir quelles sont les questions principales à poser et à se poser, réfléchir aux questions importantes pour le développement, être capable de communiquer de façon claire sur le produit attendu, savoir aller échanger et récupérer les bonnes informations pour construire la vision etc.)
Le père : En tant que ton père je souhaite que tu ranges ta chambre
La fille : Afin de ?
Assurez-vous que vos user stories sont correctement formulées
J’ai rencontré plusieurs personnes qui pensaient qu’être agile c’était être anarchique. Avancer à taton, sans codes ni méthodologie. Or, au contraire, il faut beaucoup de rigueur et d’implication pour travailler correctement en agile.
Nous voyons ainsi des PO débutants qui peuvent passer à côté du véritable sens de “ rédiger seulement le nécessaire ”. Ce principe n’a de sens que si on l’associe au fait de beaucoup communiquer en équipe et travailler avec rigueur à la construction du produit.
Il arrive que certaines personnes aient des difficultés à travailler en équipe et à collaborer. Par timidité ou manque d’habitude par exemple. Ce peut être le cas pour celles qui ont travaillé dans un modèle où la hiérarchie est très marquée et où les métiers n’échangent pas (le fonctionnel avec la technique et inversement).
Certains franchissent le pas aisément et trouvent le fonctionnement agile logique et fluide tandis que ce comportement est plus contre intuitif pour d’autres.
Il est difficile d’amener rapidement les personnes qui sont peu à l’aise avec ce modèle à adopter rapidement le bon comportement (travailler en équipe, communiquer plus systématiquement et plus horizontalement, être dans la vision du produit plus que dans la coordination du projet, etc). C’est donc par des outils (et/ou des rituels) que les bonnes pratiques peuvent venir.
En demandant ainsi aux PO de suivre le modèle présenté ci-dessus, nous les poussons à travailler d’avantages la partie construction de la vision en amont du développement.
Il faut également les inciter à travailler davantage avec les développeurs, à oser aller échanger avec eux pour pouvoir ensuite répondre aux questions sous-jacentes que soulèvent le modèle d’US ci-dessus : Est-ce que découper le produit de cette façon est cohérent ? Est-ce qu’il faut le découper encore ou la granularité est-elle bonne au niveau technique ? Est-ce qu’il faut rajouter des informations sur la partie technique pour pouvoir lancer le développement ? (wording, jeu de données etc.)
J’ai expérimenté ce modèle d’US sur des projets où initialement ni les fonctionnels ni certains développeurs n’avaient la culture agile. Sur ces projets les différents métiers se parlaient peu et la vision n’était pas partagée. Le workflow n’étaient pas fluide non plus. Après un petit temps d’adaptation et d’utilisation du modèle présenté dans cet article, tous se sont accordés sur le fait que cette façon de travailler leur apportait un confort et une plus grande fluidité dans le processus global de développement. Ils ont progressivement travaillé d'avantage ensemble et pris plus d’aisance pour construire la vision du produit. Le développement derrière s’est également grandement amélioré grâce à ce travail effectué en amont.
Enfin j’ai utilisé ce modèle à chaque démarrage de projet.
Les débuts de projets sont souvent sensibles. Nous ne partageons pas, à ce stade, une culture commune car l’équipe n’a pas encore travaillé ensemble et le sujet est nouveau. Il faut donc clarifier au maximum les échanges pour que l’énergie du démarrage soit dirigée vers d’autres éléments prioritaires du projet (poser des bases saines, apprendre à se connaître, partager la vision, s’approprier le sujet, commencer le développement, etc.). Au démarrage, détailler l’US est utile pour : s’accoutumer aux termes associés au projet, apporter du confort et de la fluidité dans le travail, partager une vision claire.
Plus on avance dans un projet, moins toutes les étapes de ce modèle sont nécessaires. Tout le monde se connaît, connaît bien le produit, le contexte, sait pourquoi et pour qui le produit est développé. Les échanges oraux peuvent également être plus fluides et spontanés.
A partir de ce moment l’US peut donc s’alléger, sans que cela n’impacte la qualité du projet et du développement.
Bien que détailler une US ne fait pas en soi partie des pratiques agiles car le ticket est quasiment auto-portant, cette pratique peut être utile dans différentes situations :
Pour que cet outil soit cohérent avec une démarche agile, il doit être accompagné de rituels et de pratiques incitant à communiquer un maximum en équipe (par exemple cadrage avec le modèle des 3 amigos, échange oral à instaurer à certaines étapes du process, présentation systématique des US en planning game, etc.).
Ce modèle, s’il est bien utilisé, n’est pas incompatible avec les pratiques agiles car il permet à toute l’équipe d’avoir une vision claire de l’attendu et d’éviter les quiproquos malheureux. La clarté dans le propos est probablement ce qui permet le plus à n’importe quelle personne de s’approprier le sujet et d’y apporter sa pierre à l’édifice en enrichissant ou challengeant cette vision.
La communication doit être avant tout inclusive. Par inclusive j’entends : que tout le monde soit en mesure de savoir ce qu’il se passe, de comprendre clairement ce qui se dit (sans ambiguité ou dissolution du message), pour que chacun puisse s’approprier le sujet et ainsi agir sur celui-ci.
Le premier pilier du manifeste agile indique qu’il faut privilégier les individus et leurs interactions plus que les processus et les outils. J’ai démontré ici comment dans certains contextes nous avons eu besoin d’outils pour faciliter ces interactions car l’agile n’est pas nécessairement spontannée. Pour nous la customisation de l’US a été la technique qui nous permet d’agilifier nos façons de travailler. Associée à un accompagnement fort, elle peut être utile dans certaines équipes qui veulent souhaitent devenir agile. C’est la raison pour laquelle je vous partage ce modèle.
Pour autant il doit être considéré comme un filet de sécurité qui aide à aller vers plus d’agilité et il n’a pas vocation à perdurer sur la totalité d’un projet. Le but ultime étant de ne plus passer par des outils aussi détaillés pour savoir travailler et interagir en groupe.
Au final chaque équipe peut construire son propre filet de sécurité si elle rencontre des difficultés à être immédiatement “agile” au sens propre du terme. Le seul élément important pour mettre en place ces outils est d’adopter une posture privilégiant un maximum la discussion et où l’écriture n’intervient que lorsqu’elle semble nécessaire.
Que ce soit en écrivant des tickets hybrides, en ajoutant des rituels ou encore en détaillant un peu plus vos DOD, à vous (équipe) de trouver votre façon de travailler et de faire évoluer ces façons de faire, pour réussir à travailler plus à l’oral et au fur et à mesure à interagir “ sans filet ”.