Le syndrome de la page blanche, ça arrive à tous les Product Owner devant écrire une User Story. Par où commencer ? Comment bien cerner le sujet ? Jusqu’où faut-il la détailler ?
Nous allons réfléchir dans cet article, en tant que Product Owner, à comment aborder et démystifier l’écriture des User Stories, bien que ça ne soit pas forcément au Product Owner d’écrire les éléments de backlog (nous en reparlerons dans un prochain article).
(disclaimer : ici, nous allons parler d’User Stories, avec le “User” dedans, mais ça reste valable pour d’autres types d’éléments de backlog)
Le canevas, (trop) bien connu ?
Souvent, en tant que Product Owner ou accompagnant un Product Owner, on peut se retrouver intimidé(e) par l’écriture de la User Story.
Oh, on a bien le canevas : En tant que… Je souhaite que… Afin de…
Mais ce n’est pas pour ça que les cases vides arrivent à se remplir facilement.
Les questions quand on débute la création d’une User Story
On se pose beaucoup de questions pour chacun des éléments constituant l’US :
- Qui est l’utilisateur concerné ?
- Comment préciser le sous-groupe de l’utilisateur cible pour que les dev comprennent bien ?
- Que veut-il vraiment ?
- Dans quel but ?
- Comment mesurer le gain ?
- etc.
Toutes ces questions demandent des réponses qui peuvent demander un certain temps pour être matures.
Du coup, on fait quoi ?
Le PO n’a pas tout le savoir
Déjà, en tant que PO, vous pouvez admettre que vous n’avez pas les informations !
Et c’est très bien !
Et c’est normal !
Et si quelqu’un vous le reproche, envoyez-le parler avec le ou la Scrum Master la plus proche.
L’US parfaite !!
À force de chercher “l’US parfaite”, on ne trouve jamais rien, car l’US parfaite est mouvante, changeante, c’est un caméléon, une brise, une odeur flottante et qui nous fait nous arrêter, réfléchir.
l’US parfaite n’est pas une chose, c’est un tout.
(ce qui ne veut rien dire, mais avouez que ça claque)
Il n’y a pas un format parfait, puisque la User Story est une invitation à la discussion comme l’a décrite Alistair Cockburn en… 1998 !
C’est un élément de conversation entre le client et les développeurs, le format parfait de l’US dépend donc de chacun, non ?
Pour une équipe A, une US très simple, quelques mots sur un bout de papier, suffira. Elle sera parfaite, car elle n’aura coûté que très peu de temps à écrire et malgré ça, elle permettra à l’équipe de développement de répondre au besoin au plus juste.
La même US, pour une autre équipe, disons l’équipe B, ne sera pas du tout pertinente. L’équipe de développement n’aura pas compris les subtilités et ne produira pas exactement le produit répondant au besoin.
Comment savoir alors ?
La collaboration, la discussion, le partage.
C’est en apprenant qu’on apprend, on n’arrive pas dans une équipe en sachant comment chacun fonctionne.
Au fil du temps, parce qu’ils sont une équipe et qu’ils se considèrent ainsi, les membres de l’équipe Scrum apprennent comment pensent les autres, ce qu’ils comprennent et ce qu’ils ne comprennent pas.
C’est ainsi que les US parfaites émergeront dans votre équipe, avec du temps.
Ne pas se prendre la tête : simplicité
Si vous acceptez le fait de ne pas tout savoir à un moment donné, que vous n’avez pas la possibilité de créer la bonne US maintenant, vous serez plus heureux et vous accepterez alors de mettre dans le backlog des éléments qui ne sont pas “prêt”.
Et oui, le travail du Product Owner est aussi itératif.
Un besoin émerge ? Hop, une mention dans le backlog pour en garder la trace.
Plus on avance vers la réalisation, plus l’élément va être affiné.
Les éléments les plus lointains d’un backlog, comme sur l’image ci-dessus ne sont pas plus gros, ils sont plus flous. Ils sont moins précis.
Ce qui à l’avantage d’être moins coûteux si on doit s’en débarrasser parce qu’ils sont devenus obsolètes ou qu’ils ont peu de valeur.
Itérez !
Itérez !
Itérez !
Ne cherchez pas à avoir la version parfaite, créez un élément dans votre backlog et revenez dessus de temps en temps pour le retravailler, en discuter avec les utilisateurs, clients, sponsors et l’équipe de développement.
Pour en savoir plus sur la User Story, l’épique et les thèmes, rendez-vous sur cet article.
Image de couverture : by Vlad Hilitanu sur unsplash