Il n’est pas toujours facile de trouver le bon timing pour écrire ses US (user-stories) afin d’optimiser au maximum leur création et minimiser la perte de temps. Je vais donc vous donner une première vision pour approcher peu à peu d’un modèle plus performant.
La proposition que je vais réaliser dans cet article n’est pas à suivre à 100% ; je la présente pour vous expliquer la mise en place d’une démarche incrémentale et itérative sur la partie fonctionnelle du produit. N’hésitez pas à créer vos propres étapes de maturation et d’adapter les timing proposés selon votre contexte.
L’approche incrémentale et itérative pour écrire ses US
Cette approche incrémentale et itérative ne s’applique pas seulement au développement mais également à la création du backlog. Préparer des user-stories complètes des semaines à l’avance est une erreur à ne pas commettre car cela va vous poser deux soucis majeurs :
- Perte de temps sur le travail effectué d’une US si celle-ci est abandonnée.
- La frustration d’avoir fait des US complètes peut pousser le PO à éviter les changements de scope (du par exemple aux feedback) volontairement.
Laissez la chance au produit de pouvoir avoir un scope agile.
Pour cela, n’hésitez pas à mettre en place un workflow de maturation des user-stories avec lequel on associera une sorte de timing. Voici à quoi ressemblerait ce workflow dans notre exemple (attention chaque équipe aura son propre workflow) :
Le but étant d’incrémenter les user-stories d’éléments au fur et à mesure du temps de vie de celle-ci.
Si nous prenons l’exemple du workflow présenté ci-dessus, voici les étapes clés de nos US et le timing que nous lui associerons de façon plus détaillée.
1/ Une vision générale avec un Story Mapping
Quand nous avons déjà réalisé une initialisation de projet ou un framing, l’idéal est d’en sortir avec un story-mapping réalisé car cette pratique permet vraiment d’obtenir une vision simplifiée du futur backlog à réaliser.
Article : Comment lancer un framing de projet ?
Cette représentation graphique propose que de simples items sous forme de post’it où nous y avons écrit le minimum pour comprendre la fonctionnalité proposée. Voici un exemple de représentation ci-dessous :
Je vous propose d’aller lire un article plus complet sur le story-mapping que j’avais réalisé il y a quelques temps.
Article : Bien comprendre la création d’un story-mapping
En cas de besoin d’avoir une roadmap estimative, il ne faudra pas hésiter à réaliser un Extreme Quotation à partir de ces items comme je vous l’explique dans l’article que je vous ai proposé sur le lancement d’un framing.
Cet exercice d’Extreme Quotation peut également permettre au Product Owner d’avoir une première vision de la charge des user-stories. En quelques mots, on peut estimer entre 40 à 100 user-stories en seulement 40 minutes.
Article : Estimons avec de l’Extreme Quotation
2/ Mes items deviennent des user-stories dans mon backlog
Le Product Owner en sortie de framing, transformera les items en user-story sans jamais entrer dans les détail.
Compléter la user-story à 100% à cette étape de cycle de vie d’une US serait totalement prématuré car nous savons que des demandes fonctionnelles pourront encore changer, disparaitre voire s’ajouter. Afin d’optimiser le temps précieux du Product Owner, il s’arrêtera au niveau du résumé de la user -story.
Par exemple l’item « Noter le produit » deviendra « En tant que Client, je souhaite pouvoir noter le produit afin de donner mon avis aux autres clients ».
3/ On développe la user-story
Quand le Product Owner pense proposer une user-story dans le prochain sprint, il va développer son contenu lors du sprint précédent.
Ici en suivant notre workflow, le Product Owner réalisera la description et les tests d’acceptances alors que le UX/UI se chargera de la partie wireframe et design.
Cette démarche d’attendre le bon moment n’est pas logique au premier abord mais elle est d’une efficacité redoutable.
4/ Proposition aux développeurs
Le Product Owner va présenter les user-stories aux développeurs pour leur soumettre à validation voire à leur estimation.
Dans quelques cas, le Product Owner s’apercevra que le travail technique est plus gros que dans son imagination mais cela n’est pas bien grave. Il la mettra en stand-by pour un prochain sprint.
=> Cependant, si le travail d’Extreme Quotation a été fait lors de la première phase de maturation, ce problème sera rarement rencontré. C’est aussi une façon d’optimiser le travail productif (soit de diminuer les pertes de temps).
Dans certains cas, les développeurs demanderont un redécoupage de la user-story ou d’un besoin d’amélioration de celle-ci. Pas de soucis, le Product Owner le fera à la suite de cette Product Backlog Refinement.
Article : La Product Backlog Refinement
A/ Les feedback en review ou démo
Quand les utilisateurs clés ou les parties prenantes feront leurs feedbacks, le Product Owner les rajoutera dans le story-mapping et dans le backlog sous la forme simple du résumé.
Il ne traitera le contenu complet de la user-story qu’au moment voulu comme il le fait avec les demandes initiales.
Conclusion
L’évolution du backlog doit également se faire de façon itérative et incrémentale. On peut même parler de PDCA car le Product Owner doit prendre note des éventuels retours des développeurs lors de la Product Backlog Refinement pour améliorer le contenu des prochaines user-stories.
Maintenant écrire des US de façon optimale n’a plus aucun secret pour vous. N’hésitez pas vous aussi à partager vos astuces aux autres lecteurs de ce blog.
12 Rétroliens / Pings