Écrit par Charlie, Scrum Master

Voilà, nous y sommes, le moment que tout Scrum Master travaillant dans le développement logiciel cherche à éviter. Nous sommes en revue de sprint, Swann réalise la démo d’une fonctionnalité et Morgan, Product Owner, réagit :

 » Ça n’est pas du tout ce que j’avais demandé ! 

– C’est pourtant ce que tu as écrit dans la user story, lui répond Swann.

– Mais tel que ça fonctionne, ça ne sert à rien ! s’emporte Morgan. « 

Cet échange, si anodin en apparence, représente pour moi un formidable aveu d’échec. C’est comme cela que je l’ai vécu.

Une user story n’est un morceau de spécification

Si je devais résumer cette situation, deux personnes de la même équipe ont eu une incompréhension à propos d’une fonctionnalité à développer. Il est donc naturel de regarder la façon dont ils ont communiqué et je tombe rapidement sur le coupable, ou plutôt sur le bouc émissaire : la user story (US). 

En servant de moyen de communication, de sorte que développeurs et PO n’aient pas à se parler, ce petit bout de papier s’est mué en un véritable mur. 

Découper la documentation exhaustive que nous appelons « spécifications » en user stories représente un anti-pattern du développement logiciel agile. 

 » Pourquoi ?  » m’avait alors demandé Morgan.

Disons qu’en agissant ainsi, nous bafouons trois des quatre valeurs du manifeste agile puisque nous avons privilégié :

  • les outils (user stories) plutôt que les interactions entre les personnes
  • une documentation exhaustive plutôt qu’un logiciel fonctionnel
  • la négociation contractuelle plutôt que la collaboration avec le client

Or l’agilité dans le développement informatique repose sur la collaboration respectueuse entre les personnes dans le but de produire des logiciels à forte valeur ajoutée pour leurs utilisateurs. D’après Extreme Programming, d’où vient le concept de user story, il s’agit du plus petit élément procurant de la valeur métier.

Rechercher la compréhension mutuelle

Alors comment expliquer que nous ayons si mal utilisé cet outil ? En fait rien n’empêche un PO de préparer des US en avance, bien au contraire ! Morgan doit cependant garder à l’esprit qu’elles n’auront de valeur qu’à partir du moment où elles auront été présentées à la Dev Team mais surtout qu’elles auront été comprises et enrichies par elle.

Dans son livre « Story Mapping », Jeff Patton illustre très justement cela de la manière suivante : si je vous montre une photo de mes vacances, vous y verrez seulement un magnifique paysage. Mais pour moi cette photo représente la journée de marche vécue, les paysages découverts, les gens rencontrés. Une fois que je vous aurai partagé tous ces souvenirs, vous en aurez la même compréhension que moi. Vous pourrez même l’enrichir, y ajouter votre expérience.

Une US ne représente en réalité que la promesse d’une discussion entre Morgan, qui représente les gardiens de phare, et ceux qui vont développer le produit, rien de plus dans un premier temps. C’est un moyen de dire : « À ce moment de l’histoire nous allons améliorer la vie ou le travail de l’utilisateur. Réfléchissons ensemble à comment y parvenir ! »

Cette discussion est donc un point de départ, le cadre dans lequel nous devons partager le besoin, comment nous allons y répondre et comment vérifier que la réponse développée satisfait au mieux ce besoin.

Une bonne pratique pour favoriser cette collaboration consiste à y impliquer le PO un développeur et un testeur : les 3 amigos.

Au final, une user story est le résultat de la compréhension mutuelle entre l’utilisateur (son représentant) et l’équipe chargée du produit. C’est la trace de leur collaboration au plus tôt dans le processus de développement.