J’ai eu la chance de participer à la formation « Améliorer vos stories utilisateurs » de Gojko Adzik à Bordeaux.

En plus du grand plaisir de retrouver quelques connaissances bordelaises et d’en faire de nouvelles, j’ai retrouvé Gojko après la première formation Spécification par l’Exemple qu’il avait donné au printemps 2013.

Comment le product owner peut prioriser son backlog?

J’ai enfin compris un truc. Pourquoi pendant tant d’année, je n’arrivais pas à faire comprendre l’intérêt de prioriser un backlog aux product owners.

En fait, ce n’est pas l’intérêt qu’ils n’avaient pas assimilé, c’est comment faire.

Bien évidemment, tout bon product owner souhaite que son produit soit fait dans le bon ordre : ce qui apporte de la valeur doit être fait en premier. Le “right product”, “build the right product and build it right”. Avec Nicolas Gouy, nous avions déjà quelques bonnes pistes pratiques pour cela dans son livre “Agile with Guts“. Déjà Gojko avec son impact mapping aussi.

Avec ces outils, il est facile partant d’une page blanche de construire son backlog priorisé pour définir son MVP.

Le problème est lorsque le product owner a déjà son backlog.

Ce qui me manquait, ou manquait aux product owners, c’est un moyen simple de prioriser le backlog.

Mais comment faire avec un backlog de plus de 200 histoires ?

Le découpage du backlog

Le découpage du backlog en histoires utilisateurs nécessite une finesse due à la taille des itérations, c’est ce qui fait qu’un backlog est souvent trop détaillé, trop gros pour qu’un product owner puisse s’y retrouver. Les histoires doivent être INVEST, c’est très bien, mais le S’mall est fait pour que l’équipe de développement ait des fonctionnalités suffisamment petites pour pouvoir les produire en un sprint. Ce n’est plus à l’échelle de priorité du product owner, c’est trop fin. Alors comment faire?

Et là Gojko m’a enfin permit de comprendre le truc!

En deux points:

Entrée, Sortie, Résultat

 et

Maintenant ou Pas maintenant.

Entrée, sortie, résultat

En anglais, ça donne ça : inputs, outputs, outcome

Chaque histoire du backlog peut être vu du point de vue de l’utilisateur comme soit une entrée, soit une sortie et il en retire un résultat, de la valeur.

Les entrées (input):

“En tant que Paul, je veux saisir mon login/mdp”, c’est une entrée.

“En tant que conseiller clientèle, je veux pouvoir ajouter un nouveau client dans ma base clientèle”, ouaip, super, c’est une entrée.

Cela ne rapporte rien directement, c’est indispensable mais sans plus-value.

Il n’y a pas de “afin de” direct.

Les sorties (output):

“En tant que chargé clientèle, je veux connaître mes clients ayant plus de 1M€ sur leur compte”, c’est une sortie.

“En tant que pilote, je veux savoir à quelle heure j’arrive à destination”, c’est une sortie.

Là on peut préciser “afin de”. Afin de quoi? d’avoir un résultats, un outcome.

Afin de pouvoir les relancer pour leur proposer une carte privilège mega-master-gold-platinium-de-la-mort-qui-tue (ben oui à 1M€, quand même!)

Et c’est là que tout se lie. Votre backlog peut être filtré, trié, rangé, priorisé à l’aide de cette typologie : entrée, sortie, résultat. Comment?

Les résultats (outcome):

Et bien il faut repartir en amont, reprendre de la hauteur sur le backlog.

Il faut pouvoir connaître les résultats attendus de votre produit. Pour cela Gojko propose d’utiliser l’impact mapping, carte d’impact.

En quoi et de quelle façon votre backlog va impacter l’activité de l’utilisateur final.

Comment faire pour qu’un client achète mieux, plus vite, qu’un chargé de clientèle augmente son taux de conversion de nouveaux clients, qu’un pilote d’avion diminue sa consommation de kérosène ou limite son temps d’arrêt à l’escale. Je n’irai pas plus loin dans la description de l’impact mapping ici, ce n’est pas le sujet.

Maintenant ou Pas Maintenant :

Avec l’impact mapping, une fois l’impact défini, il peut être priorisé : Maintenant ou Pas maintenant (Now or Not Now).

Le principe de Gojko est simple. Il n’y a pas de priorité 1, 2, 3, ou Must, Should, Could…

C’est binaire, ça ne peut que plaire à des informaticiens!

Juste Maintenant ou Pas maintenant.

Il suffit donc de choisir quel impact on souhaite produire lors de la prochaine itération (je ne parle pas de sprint, mais d’itération, donc livraison)

Pour cet impact on construit le story board, puis on peut choisir les histoires qui feront parties de ce MVP en suivant le chemin de l’impact vers le résultat (outcome), les sorties apportant ce résultats (output), et les entrées indispensables pour cela (inputs).