Ca Scrum !

Lors du dernier Sprint du projet Marguerite, l’équipe avait l’impression de ne travailler que sur des User-Story peu importantes (d’un point de vue métier), pour ne pas dire cosmétique. Elle avait l’impression d’avoir perdu la « vision » du produit et ne comprenait plus les priorité métier.

En tant que ScrumMaster

Je veux que l’équipe projet ait le sentiment de produire de la valeur métier dans un logiciel utile

Afin que l’équipe reste mobilisée sur le projet !

Je suis donc allé voir le P.O pour parler avec lui du Backlog (et du manque de compréhension qu’en avait l’équipe).Voici un petit résumé de ses principales interrogations :

• Quel degré de précision dois-je avoir ?
• Je ne connais pas totalement tout le contenu du projet, alors j’ai du mal à organiser mes idées
• L’équipe attend beaucoup de moi et comme ce métier (P.O) est nouveau je me met une pression qui me fait perdre mes moyens : je perds un peu moi même la vision des priorités : je comprends que l’équipe s’en rende compte.

Je lui ai donc proposé 2 séances de travail de 2 heures.

Premier atelier : définition des Features

Les Features sont des fonctionnalités macroscopiques assez facilement identifiables.  En repartant du StoryMap (lire : du MindMap au backlog) que nous avions un  peu trop vite délaissé, nous sommes arrivé à 20 Features écrites sur des post-it. Maintenant que le périmètre métier est visible, nous pouvons nous occuper de la priorisation : pour cela, je lui ai proposé d’utiliser la méthode MoSCoW (Must, Should, Could, Won’t). L’objectif est clair : ce qui sera identifié en « MUST » sera le contenu de la première release. Je lui ai aussi rappelé qu’il gardé la possibilité de « modifier » ses priorités entre 2 Sprints ! J’ai vu à ce moment là dans ces yeux comme un poids qu’on lui enlevait de  ses épaules : il venait de comprendre la « puissance » des itérations. L’itération ne concerne pas seulement la production du produit : c’est tout le processus Scrum qui est itératif ! Avec un jeu de pastilles colorée, il ne lui aura fallut que 10 minutes pour prioriser le contenu du produit.

Deuxième Atelier : Des Features au backlog

Maintenant que le P.O a retrouvé sa vision produit, il peut maintenant se concentrer dans la réécriture du Backlog. « Chaque Feature donnera naissance à 10-15 User Stories. Nous avons 20 Features : il faut donc que nous écrivions 200 US en 2 heures ?  » Evidemment que non.

Pourquoi écrivons nous un backlog ? Pour que l’équipe sache sur quoi elle va s’engager lors du Sprint, …  , mais surtout pour que l’on ai une vision priorisée du produit : Qu’est-ce qui est le plus important dans le produit ? Où se cache la valeur métier ? Quel seront les prochains besoins métier à produire ? De nouveau, il nous « suffit » d’être pragmatique :ce qui est prioritaire doit être suffisament détaillé (De la taille d’une User Story) mais ce qui est « au fond » du backlog, c’est à dire ce qui est moins prioritaire, n’a pas le même besoin de précision pour l’immédiat !

Nous avons donc décidé de nous concentrer sur les 4 premières Features. En 1 heure, elle sont posées sur des Post-it (Formalisées et avec les critères d’acceptation) !

 

 

 

Pour l’aider à valoriser ses User Story, je lui ai proposé de définir des critères de valeurs ‘objectifs’ et de valoriser ces critères :

• Est-ce que cela concerne beaucoup d’utilisateur ? (5 Points)
• Est-ce que cela rapporte du Chiffre d’Affaire ? (8 Points)
• Est-ce que cela simplifie la gestion de l’entreprise (3 Points), etc …

Avec cette matrice d’évaluation, il ne lui a pas fallut plus de 10 minutes pour valoriser puis prioriser les 47 Users Story qu’il venait d’écrire. Même si cette méthode a ses limites, elle permet au P.O de pouvoir s’appuyer sur un élément objectif pour l’aider à décider.

Lundi matin, nous avons donc présenté ce « nouveau » backlog qui contenait « tout » le projet, priorisé, valorisé, et suffisament détaillé  pour l’équipe. Les discutions entre le P.O et l’équipe pour la compréhension des Story était beaucoup plus détendue qu’à l’habitude car le P.O avait le sentiment de comprendre, de maitriser son produit. Ce fût, pour l’équipe, le meilleur Sprint Planning Meeting du projet.