Dis, ça nait comment une User Story ?

Un Product Owner est-il un expert fonctionnel tout domaine ?

La science infuse du super Product Owner

En arrivant sur ma mission actuelle, j'ai découvert la légende urbaine de la naissance d'une User Story : a priori, une User Story germait dans la tête d'un super Product Owner et, cinq minutes plus tard, elle était écrite sur un post-it.

S'il est vrai que j'ai des superpouvoirs (inutile de le nier), je dois avouer ici que je ne suis pas incollable sur tous les sujets fonctionnels du marché et que je suis incapable d'écrire une User Story sur n'importe quel sujet et en un clin d'oeil. Il m'arrive d'avoir besoin d'aide.

Un deuxième cycle itératif moins connu

Si l'on connaît bien le cycle itératif du développement des User Stories lors de Sprints, on connait moins le cycle itératif qui permet d'obtenir le backlog produit.

Si le rôle du PO est de suivre le développement d'une User Story, du Sprint Planning à la démonstration de fin de sprint, il en existe un autre, moins connu des développeurs mais qui occupe pourtant une majeure partie du temps du PO : faire naître la User Story.
Contrairement à la légende urbaine, la User Story ne naît pas dans un Backlog, elle naît d'une idée Métier ; une idée plus ou moins aboutie, plus ou moins fouillée selon l'urgence, le Métier, la taille du projet, ... une idée qu'il va falloir beaucoup travailler avant de la retrouver sur un post-it.

Si le worklow le plus connu de la User Story est celui du sprint, il ne représente que 20% de la vie de l'US, les 80% sont en amont, ils peuvent démarrer des semaines, des mois avant le sprint et se déroulent aussi selon des itérations.

De la naissance de l'US à sa présentation en Sprint Planning

Lors du démarrage d'un projet, la User Story ne porte pas encore son nom, elle est contenue dans une idée Métier qui va être découpée, précisée, challengée.

C'est lors d'ateliers que le Product Owner va monter en compétences sur le sujet fonctionnel grâce à ses interlocuteurs métier et qu'il va les aider à creuser leur besoin. Grâce à sa compréhension technique, il peut même orienter ce besoin en fonction des possibilités techniques (sans freiner pour autant l'expression du besoin).

Lors de ces ateliers, le besoin va être découpé en Features (ensembles de besoins) qui vont être ordonnées, affinées et priorisées pour déboucher sur un Story Map de grosses User Stories (ou d'Epics) représentant le besoin initial débarrassé de son superflu.

A l'issu des ateliers, le Product Owner va redécouper les Epics pour coller à la taille de l'équipe, à la vélocité. Il va les compléter avec des cas de tests passants, non passants, des maquettes. Certaines nécessiteront même peut-être une étude technique avant de trouver une place dans le Backlog Produit puis dans le Backlog d'un Sprint.

Le chemin est long pour qu'une idée arrive dans le Backlog d'un sprint. En fonction des délais, du budget, du périmètre à couvrir, le petit bout d'idée qui allait déboucher sur notre User Story, va peut-être même être dépriorisé ou abandonné et ne va jamais finir sur un post-it de Sprint ni même être présenté aux développeurs.
Combien d'idées ne sont jamais transformées en User Stories ?

Alors cette légende ?

Si le Product Owner n'est pas un super héros capable d'écrire des User Stories sur tout sujet en 5 minutes, il est capable de découper une idée Métier, sur tout sujet, au fil des semaines, en un ensemble d'éléments priorisés, indépendants, suffisamment petits pour être développables dans une partie de sprint, qui, mis bout à bout, correspondent à l'idée Métier de départ.

Si être capable de transformer une idée Marketing en une fonctionnalité répondant aux besoins de plusieurs millions de français ne relève pas du super héros, je remise ma cape et mon collant au placard.