Pourquoi le Product Owner ne doit pas préparer ses user-stories en avance ?

Il arrive souvent que le Product Owner se lance dans la préparation de user-stories complètes des mois à l’avance.

Qu’est-ce qu’une user story complète ?

Imaginez à présent que le Product Owner écrive 50 user-stories complètes à l’instar de l’exemple ci-dessus. Pour un volume aussi important de user-stories écrites les unes après les autres, ce travail débouche forcément sur des comportements non pertinents et non adaptés pour le produit informatique final. En outre, avec cette façon de fonctionner, on s’éloigne considérablement d’une méthodologie de travail fondée sur l’agilité.

Un scope projet difficilement flexible

Quand ce travail est réalisé trop longtemps en amont à défaut d’être entrepris « juste à temps », c’est-à-dire au moment opportun, le scope du projet n’est plus du tout flexible et il devient rigide.

En effet, il est très compliqué de modifier une user story déjà écrite. Dans le cas où vous allez modifier le comportement d’une user-story, cela vous obligera à devoir repasser sur les 49 autres user-stories. C’est à ce moment-là que l’on fait des erreurs et que l’on manque des comportements et changements qui affectent le produit final. Ce qui est somme toute normal, quelle personne serait capable de conserver une attention sans faille dans la lecture successive de 50 user-stories ?

La qualité fonctionnelle du produit s’en trouvera impactée négativement. pire encore, des développements seront gaspillés pour corriger les manques sur les user-stories qui n’ont pas été mises à jour.

Enfin, la marge de manoeuvre étant très limitée, nous allons avoir tendance à éviter de trop modifier le périmètre du projet afin de minimiser le nombre d’erreurs. Ce qui est encore pire et qui prouve que nous ne travaillons plus du tout en mode agile.

Juste-à-temps : écrire ses user-stories au fur et à mesure

Il est préférable d’écrire ses user-story au fur et à mesure que le projet avance. En effet, écrire en amont du projet les 50 user-stories pourrait faire penser que l’on va gagner du temps, et cela même si le Product Owner a une excellente vision de son produit. Mais c’est tout le contraire qui va se passer et c’est surtout ne pas prendre en compte les imprévus d’un projet, et il y en a toujours.

Les imprévus représentent les retours d’expérience, les feedbacks des utilisateurs, la réalité des fonctionnalités développées et livrées etc. C’est en ayant connaissance de tous ces éléments qu’il est conseillé de se lancer dans la rédaction de user-stories au fur et à mesure que le produit est développé.

La user-story ainsi rédigée juste-à-temps sera beaucoup plus juste et pourra partir dans le prochain sprint de développement.

La phase d’estimation : quand on se rend compte que la moitié des users-stories ont été écrites pour rien…

Autre exemple intéressant, un story mapping complet sur un produit a été réalisé. Toutes les user-stories ont été écrites. Lors de l’étape de l’estimation, l’équipe se rend compte que la moitié des user-stories ne rentreront pas dans le budget alloué au projet. Tout cela sans prendre en compte les retours utilisateurs durant les tests fonctionnels et autres imprévus.

On se retrouve alors dans une impasse où seulement 30 % du produit pourra être réalisé avec l’enveloppe budgétaire prévue. Sauf si une enveloppe supplémentaire est trouvée pour permettre de réaliser l’entièreté des développements.

Tous ces exemples témoignent bien du fait que le Product Owner ne doit surtout pas écrire toutes les users-stories complètes de la solution informatique trop en amont. Car cette façon de faire est contraire aux préceptes agiles.

Bocasay accompagne les PME dans leur transformation numérique

Bocasay est une société informatique qui possède différents services liés à l’externalisation IT :

• Constitution en moins de 4 semaines d’une équipe de développeurs,

• Sous-traitance web en développement front-end, back-end et full stack,

• Accès à des ingénieurs informatiques sur un panel large de technologies,

• Conseils et accompagnement sur l’organisation du projet et la mise en place d’outils et méthodes,

• Accompagnement dans toutes les phases de cycle de vie du projet : conception informatique, développement, tests d’acceptance, maintenance informatique,

• Offshore à Madagascar et offshore au Vietnam,

• Développements de logiciels, d’applications web, mobile.

Retrouvez tous les épisodes de la série [ÊTRE AGILE] :

[ÊTRE AGILE 1/4] Pourquoi faire un sprint zéro ?

[ÊTRE AGILE 2/4] Quel est le rôle du Product Owner dans le développement d’un logiciel ?

[ÊTRE AGILE 3/4] A quoi sert vraiment le sprint review dans le développement d’un logiciel ?

Toute l’actualité sur les développements informatiques externalisés est sur le blog de Bocasay.

Source : myagilepartner.fr