03/01/2019

Exploration du backlog avec des dessins

Lors d'échanges avec des personnes qui découvraient l'agilité, j'ai dessiné un petit schéma représentant la manière dont les Story permettent petit à petit de répondre à un besoin. J'ai trouvé cette image pertinente et qu'il y avait beaucoup de choses que je pouvais expliquer à partir de ce dessin.

Je vous emmène donc vers une exploration du Backlog,  à travers des dessins.


Le nuage représente le besoin utilisateur, qui peut être flou (ou même infini), en particulier en début d'un nouveau produit, car il y a beaucoup d'idées et de questions. Nous allons voir que ce flou n'est pas du tout un problème. Il est même normal que les utilisateurs ne sachent pas exactement ce qu'il veulent, que ce soit seulement en voyant les écrans de la première version qu'ils aient des remarques et des propositions pour la suite. Car ils ont le droit de changer d'avis, et que l'agilité propose un réponse à ce changement constant du produit et de son environnement.

Le carré représente le périmètre d'une User Story tel qu'elle est défini au moment d'un Sprint Planning. Que la story soient définie à l'écrit ou à l'oral. La transparence représente les inconnues de la story. La story a pu murir dans les semaines précédentes pour devenir plus 'opaque'.


Lors de la définition d'une User Story, le Product Owner présente la story, et elle doit être assez précise pour que l'équipe puisse estimer et commencer sa réalisation, disons à 80%. (Ce pourcentage est complètement abstrait, c'est juste pour expliquer mon propos)


Si la story n'est pas suffisement précise, définie seulement à 10% mais qu'elle est quand même prise dans le sprint, le besoin va être complètement découvert durant sa réalisation. L'estimation en story point ne peut être correcte dans ce cas. Il est préférable de faire cette exploration avant la réalisation de la story. Lorsque l'incertitude porte sur des éléments fonctionnels, il est possible de faire des ateliers avec les utilisateurs ou experts fonctionnels. Lorsque l'incertitude porte sur des éléments techniques, il est possible de faire un Spike ou Preuve de concept, c'est à dire une story qui a pour objectif de tester un nouvelle technologie. Lorsque l'incertitude porte sur le design général de l'application, il est possible de faire une maquette ou un 'mock-up'. Cela peut montrer également que le sprint Planning n'a pas été assez préparé. Le Scrum Master peut aider le Product Owner à vérifier que les story soient prêtes. Les séances de Grooming peuvent aider à faire ces vérifications de manière régulière en cours de sprint.


Par contre, si l'on cherche à obtenir des story complètement précise, à 100%, avec une Defition of Ready trop rigide, peu de story pourront être prises. Dans le cas extreme, l'équipe n'a plus de story à mettre dans son sprint. C'est ce qu'on appelle la paralysie d'analyse. En effet l'équipe doit trouver le juste équilibre entre refuser une story car la règle de gestion principale de la fonctionnalité est inconnue, ce qui semble raisonnable, et refuser une story car elle ne connait pas le texte exact d'un bouton, ce que l'on peut qualifier de jusquauboutiste, voire de mauvaise foi.


Une autre erreur possible est d'avoir des story trop grosse. Dans ce cas elle s'étale sur plusieurs sprints, entrainant un effet Tunnel. Il est recommandé de découper cette Story.

Ce dessin montre comment les itérations successive peuvent à un moment s'écarter du besoin réel, mais être réajusté en cours de route à la story suivante.

Idéalement les story successives permettent de couvrir le besoin. Mais le produit peut être utilisé avec une première mise en production rapide, afin que le feedback du terrain (et parfois anomalies détectées), viennent enrichir le backlog de manière encore plus pertinente que les idées du backlog initial.

Ces variations tournent toutes autour de la 'Definition of Ready'. Cette définition doit être partagée dans l'équipe avec le Product Owner. Cette définition peut être régulièrement ajustée au cours des rétrospective, pour être souvent enrichie, parfois adaptée ou allégée. Chaque équipe pourra trouver ce qui convient le mieux à son contexte, son outillage, son niveau d'expérience.