Mon premier PO Dojo, et ce que j’y ai appris

En attendant que je retrouve la BD du PO Dojo, voici l’esquisse, empruntée à @ramuncho

Il y a quelques semaines de ça, comme je le fais chaque année, je me suis inscrit à Agile Tour Bordeaux.

Bien que n’étant ni développeur, ni chef de projet, ni coach agile — le public-type des Agile Tour (?) — chaque année, je repars d’Agile Tour Bordeaux nanti d’un nouveau savoir, d’un outil utile, de précieux contacts… Jamais les mains vides. Par exemple, après l’édition 2011, j’avais derechef mis en application un innovation game « buy a feature » que j’avais découvert à Agile Tour (mon billet).

Cette année, j’ai appris le principe et l’intérêt du PO Dojo. Et je compte bien l’utiliser dès cette année avec mes étudiants !

PO Dojo, qu’es acquo ?

Un atelier d’une vingtaine de participants, où l’on t’explique d’abord que, à l’instar des programmeurs, qui s’entrainent à coder comme des ninja dans des « Coding Dojo », les product owner, ou PO, (tu ne sais pas ce que c’est ? Va donc lire ce billet de Fabrice Aimetti : Caractéristiques d’un Product Owner) peuvent aussi s’entraîner à devenir de bons PO en effectuant des exercices dans le PO Dojo.
Entrainement, dojo… ça sent pas un peu la SUEUR, cette affaire ?

Le principe, c’est, comme en sport, d’apprendre, et se perfectionner, par la pratique.

Là, Emilie Franchomme (@EFranchomme) et Irène Doan (son dernier billet et aussi sur Twitter @idetido), nos deux coaches, nous expliquent, mode d’emploi individuel à l’appui, que nous allons réaliser les actions du PO pour passer d’un besoin ou idée marketing à une user story prête pour la planification, pour à la fin :
– savoir écrire et découper des user stories
– savoir définir ses critères d’acceptance
– savoir écrire les tests d’acceptance
En effet, elles nous proposent la variante de PO Dojo « USTA », pour User Story et Test d’Acceptance.

Le déroulement

1. Expliquer la finalité de la session et… le déroulement.

2. Laisser se répartir l’assistance en binômes (trinômes possible ?)

3. Énoncer la demande / le besoin qui va faire l’objet d’une formulation en User Story
Pour nous c’était « je suis utilisatrice de gégémail, je veux pouvoir envoyer un mail à mon boss après être partie pour qu’il croie que je travaille tard » OK ?

4. Faire tourner 3 itérations de 3 étapes chacune :
4.1. travail des binômes 10 mn
4.2. exposé de chaque binôme 1,5 mn
4.3. partage entre binômes 10mn

Et 5. débriefing de l’atelier

Ce que j’ai appris lors de cette session

Tout d’abord, je retiens l’expérience de l’interaction ultra rapide et efficace avec mon binôme, comment on arrive à être d’accord avec très peu de mots. Et que 10mn, ça passe très très vite !

Ensuite, constater que, bien que l’expression du besoin ait été pédagogiquement calibrée pour l’exercice, son interprétation sous forme de User Stories puisse être si différente selon les binômes !

Et de me rendre compte qu’il n’est pas si facile en 10 mn, lors de la 1e itération de, non seulement formuler la US, mais aussi les critères d’acceptance. Quant aux tests, ils sont sacrifiés… Mais c’est aussi le cas pour les autres groupes.

Aussi, l’expérience de la 2e itération, dans laquelle on prend en compte le regard des autres binômes, en altérant notre user story, en y injectant ce que nous avons retenu des autres. Importance de l’échange et de ne pas spécifier « dans sa bulle ».

Et constater que l’exercice fonctionne, car dès la 2e itération, on est, pour ainsi dire, au carré avec les critères et les tests. Notre User Story est en bonne voie vers Ready !

Quant au contenu de la compétence de PO

Critères d’acceptance : en fait, ce sont des fonctionnalités. Ah… OK !
Quand une US ne possède pas de critères d’acceptance, le Scrum Master (ou équivalent) peut considérer cette story auto-validée. Autrement dit : quand la US sera livrée, vous n’aurez aucun argument pour la refuser. Et pour cause ! Une bonne motivation pour ne pas négliger les critères… D’autant plus que les tests d’acceptance permettent de spécifier l’indispensable « Definition of done ».

Les Tests, pour être jouables, il sont composés de 3 éléments :
* initialisation : les conditions dans lesquelles on se trouve au moment du test
* L’action à réaliser (possibilités de cas réel avec des valeurs)
* le résultat attendu de cette action

Definition of Ready : un concept clé qui permet de déterminer à quelles conditions une US est prête à être injectée dans une prochaine itération :
* elle a des tests
* elle est maquettée
* elle est estimée (certaines équipes estiment qu’il est suffisant que la US a été débattue, même si elle n’est pas vraiment estimée)

Sur l’importance de l’estimation
Au delà de son utilité pour prioriser parmi les US, l’estimation garantit que les développeurs on analysé la US. En revanche il est recommandé de ne pas perdre de temps à estimer des US qui ne seront peut être pas développées ; donc on ne soumet à l’estimation que les US qui s’approchent d’une itération.

L’un des rôles clés du PO, c’est de prioriser parmi les US, afin de décider celles qui seront à développer lors de la prochaine itération. Question : qu’est ce qui détermine la « valeur » qui permet au PO de prioriser ?
Cette valeur est déduite de plusieurs facteurs selon le point de vue des parties prenantes au projet :
* la valeur d’usage (point de vue des utilisateurs)
* la valeur métier (point de vie de l’exploitation)
* la valeur business (point de vue du commanditaire)
* et éventuellement l’évaluation (indicateur de « coût »)

Vous l’aurez compris, je suis un adepte du PO Dojo désormais et j’entends bien propager mon expérience. À commencer par mes élèves de M2 Multimédia à l’ISIC / Bordeaux III, et de Licence Pro e-marketing de l’Université Bordeaux IV.

Edit du 2 février 2014 : Claude Aubry, de Scrum, Agilité et Rock’n roll décline sa pratique du POdojo : le Story Dojo

Ce contenu a été publié dans e-business, avec comme mot(s)-clé(s) , , , . Vous pouvez le mettre en favoris avec ce permalien.