Quand le Product Owner préparait ses user-stories à l’avance…

Il arrive encore de voir des Product Owner préparer leurs user-stories à l’avance (quelques mois en avance). Quand ils sont formés à faire des user-stories complètes, cela devient même encore plus problématique.

Pourquoi ne pas préparer ses user-stories à l’avance ?

Quand on détermine un format de user-stories complètes comme par exemple le story A4, chaque user-story impose beaucoup de travail. Multiplié par une cinquantaine de user-stories, le travail devient non négligeable et son coût n’est pas anodin.

Voici à quoi ressemble par exemple des user-stories en story A4 :

Quand tout ce travail est réalisé pour une cinquantaine de user-stories, ce travail amène souvent à de très mauvais comportements ou à des risques importants de sortir de ce mindset agile.

Un scope qui devient difficilement variable

Malheureusement, quand ce travail est fait en amont au lieu d’être réalisé en juste à temps, le scope perd totalement de sa variabilité. Comment changer des fonctionnalités quand l’ensemble des user-stories sont déjà écrites ?

Certes cela n’est pas impossible mais imaginez le risque important d’oublier de modifier des user-stories impactées quand nous désirons modifier le comportement d’un scénario complet sur le produit à réaliser ?

Même en repassant sur les 50 user-stories au fur et à mesure, ne risque t’on pas de louper certains éléments ? Qui peut garder une attention intense sur la lecture successive de ses 50 user-stories ?

Honnêtement, le risque de dégrader la qualité fonctionnelle du produit est très élevé avec ce type de pratiques ; je ne parle même pas des pertes de temps successives au développement pour rattraper les erreurs qui s’accumulent dans les user-stories qui ne seraient pas à jour.

Pire encore, le cas où nous éviterons de changer le périmètre pour limiter au maximum ce type d’erreurs… Mais là, nous sommes dans un cadre où l’agilité n’existe plus du tout.

Le juste-à-temps est aussi une remise en question continuelle

En effet, le fait d’écrire ses user-stories au fur et à mesure (à partir d’une vision déjà définie) permet d’écrire celles-ci au bon moment. Des éléments réalisés, des feedbacks et l’expérience permettent d’être plus juste dans l’écriture de la user-story qui partira en développement dès le prochain sprint.

Peut-on vraiment deviner tout en amont avec l’enchainement de l’écriture des user-stories ? Je pense vraiment que c’est utopique de la penser même si le Product Owner a une excellente vision de son produit.

Quand les estimations amènent son lot de mauvaise surprises

J’ai rencontré un cas que je vous partage car il est intéressant. Nous avons réalisé un story mapping complet du produit imaginé. Bien que l’ensemble des user-stories étaient déjà écrites, on s’aperçoit rapidement que le périmètre de ce qui était attendu était relativement important.

En réalisant un Extrême Quotation avec l’équipe de réalisation qui travaille ensemble depuis un an, nous avons vite réalisé que seule la moitié du périmètre pourrait être développé par rapport à l’enveloppe budgétaire allouée ; et cela dans le cas le plus optimiste.

Nous pouvons rapidement comprendre qu’avec les feedbacks utilisateurs qui peuvent amener le produit à changer et les problèmes rencontrés de toute sorte, seuls au mieux 30% du périmètre déjà 100% écrit sera livrable.

Sans même parler de possibilité de trouver du budget supplémentaire (souvent complexe dans les grandes structures), 70% des user-stories ont été écrites pour rien… Une perte très importante qui s’ajoutera aux modifications qui devront continuellement être réalisée pendant la réalisation du produit.

Le juste-à-temps n’est pas une mode mais une nécessité

Vous comprenez mieux à présent pourquoi il ne faut pas que le Product Owner prépare ses user-stories à l’avance (de quelques mois). Cette façon de faire apporte son lot de problèmes, de pertes de temps et le risque de perdre son agilité.

Voici un article qui devrait vous aider à bien comprendre ce fonctionnement qui donne un maximum de chance à votre agilité :

Comment écrire ses US avec une approche incrémentale et itérative