Le backlog est vivant, il bouge avec des feedbacks (épisode 5 - le Backlog bouge)
Début de l’itération 2. Charlotte boude dans son fauteuil. Elle joue avec l’application. C’est dur tout de même d'encaisser toutes ces remarques. Mais en même temps ils ont raison. Elle voit bien qu’elle apprend une leçon rapidement, et qu’en rejouant une heure après la leçon n’était pas vraiment acquise.
Elle joue longtemps, comme pour retarder le moment où elle casse tout pour continuer. Oui car prendre en compte les remarques va impliquer des modifications sur ce qui a déjà été fait.
Il va falloir refaire quelque chose qui fonctionne déjà.
Refaire.
Je déteste refaire, se dit Charlotte.
C’est pour la bonne cause, se rassure-t-elle.
Refaire pour faire mieux.
Tout en jouant, elle compte les feedbacks.
Et il y en a beaucoup, des feedbacks.
Vus lors de la discussion entre le PO et les utilisateurs :
- créer une idée “jouer avec plus de kanas”
Vus lors de la conversation entre le développeur et le PO :
- créer une idée “apprentissage”
- créer une idée “deviner le kana”
- créer une idée “choisir de deviner le kana ou le romaji”
- créer une idée “historique des résultats”
Autre chose.
Elle a bien noté que l’ergonomie n’était pas festive. Comme les remarques étaient douloureuses, ils n’en n’ont pas rajouté avec l’interface, ils ont été gentils. Elle a bien senti que ce n'était pas satisfaisant.
Vu par le PO :
- créer une idée “améliorer l’ergonomie mobile”
Voilà voilà voilà.
Le plus rigolo c’est que Charlotte avait déjà prévu des choses à faire pour la prochaine itération.
Elle avait prévu de continuer l’apprentissage en dessinant les kanas, en écoutant les sons des kanas… et elle va devoir s’arrêter sur l’apprentissage.
Ok donc le backlog c’est une chose vivante, ça bouge.
Elle a bien compris la gravité de la situation : une application d’apprentissage doit permettre de faire des apprentissages. Elle privilégie le retour “jouer avec plus de kanas”. Elle cherche à le reformuler correctement. Quelle nouvelle promesse doit-elle écrire pour ça ?
C’est clair.
L’itération 2 sera : « Vous allez apprendre progressivement. »
Logiquement, les promesses suivantes seront :
L’itération 3 : « Vous apprendrez ce que vous voulez. »
L’itération 4 : « Vous allez connaître votre progression. »
Maintenant elle identifie les impacts dans le backlog. Une seule idée survivra, les autres attendront. Trois nouvelles idées sont créées.
Elle s’attarde un peu sur le choix des mots, elle comprend combien il était important de bien exprimer l’intention. Elle se réfère à l’intention initiale pour vérifier. Pour ne pas se tromper.
« Vous allez apprendre progressivement », c’est un plan en 4 étapes :
- Afin de savoir reconnaître des kanas, en tant que Charlotte, je veux voir des romajis
- Afin de me concentrer sur ma leçon en tant que Charlotte, je veux voir uniquement la leçon
- Afin de progresser doucement, en tant que Charlotte, je veux suivre un plan d’apprentissage
- Afin de maîtriser les kanas en tant que Charlotte je veux deviner un kana parmi tous les kanas que j’ai déjà appris
Elle discute avec son développeur préféré, la conversation est toujours riche et lui permet de peaufiner ces idées. À la fin de l'après-midi, les conversations ont fait émerger la spécification nécessaire pour développer.
Maintenant elle s'apprête à « casser » le code avec plaisir. Elle sait où elle va, et le résultat sera meilleur que le précédent.
Une nouvelle question arrive, comme ça : « Aurait-elle pu imaginer ces idées au début ? »
Elle y réfléchit à peine, finalement elle avait mal réfléchi à son produit au départ. C’est bizarre, elle ne voit pas où était son erreur de raisonnement.
Elle laisse cette réflexion culpabilisante pour plus tard.
épisodes :
2 – pour découvrir le produit, il faut le construire
4 – les utilisateurs seront ravis
5 - le backlog bouge
7 - la PO n'est pas certaine, elle pourrait aller plus vite