Écrit par Wissem, partie prenante,

Que cette journée fut stimulante !

J’ai participé au premier atelier de priorisation pour le nouveau produit de communication des phares.

A l’invitation du Product Owner et du coach Agile l’équipe s’est retrouvée pour un après-midi avec les responsables et expert-e-s des différents services Métier ainsi que quelques des futurs utilisateurs et utilisatrices. 

Sacha, coach Agile, a commencé à nous rappeler l’importance de la priorisation dans la vision Produit : 

“L’objectif étant de maximiser la valeur produite, il faut s’assurer de commencer à travailler sur les fonctionnalités qui vont apporter le plus de valeurs aux personnes qui vont utiliser l’application. Nous allons aujourd’hui initialiser le backlog, c’est-à-dire la liste des tâches priorisées qui sont nécessaires à la construction de notre produit.”

Le Product Owner a ensuite repris la vingtaine de fonctionnalités issues des réflexions des participants aux ateliers de Design Thinking. En 15 minutes chacune des fonctionnalités à été présentée à l’audience.

Sacha nous a ensuite distribué à chacun la somme de 5000€ en faux billets (malheureusement).

“Ces billets vont vous permettre d’acheter des fonctionnalités, ils vont représenter la valeur ajoutée que vous voulez apporter aux utilisateurs. Chaque fonctionnalité que l’on vient de vous présenter à un coup qui est basé sur une première estimation par l’équipe de dév de l’effort à fournir pour les réaliser” nous expliqua Sacha.

C’est ce qu’on appelle communément le ROI (Return on Investment), le rapport entre la valeur amenée par la fonctionnalité divisée par l’effort nécessaire pour la réaliser. Une fonctionnalité à forte valeur ajoutée mais avec un gros effort de développement nécessaire aura ainsi le même ROI qu’une fonctionnalité à faible valeur ajoutée mais à faible effort de développement.

J’avais déjà discuté de l’objectif de cet atelier avec le Coach. En plus de permettre une première priorisation du backlog, il a aussi pour but d’accorder tous les acteurs du projet sur la même longueur d’ondes en favorisant les débats.

Une utilisatrice présente s’étonnait que tout le monde ait la même somme de billet à sa disposition, ce à quoi Sacha répondit qu’un donneur d’ordre n’était pas plus à même de connaître le besoin des utilisateurs qu’un utilisateur lui-même, c’est pour ça que tout le monde se trouve sur le même pied d’égalité pour cet atelier.

La première session d’achat est lancée, on a tout de suite vu que les personnes hésitent à mettre des grosses sommes sur les tickets les plus chers. Cela nous a bien montré que parfois certaines fonctionnalités nécessitent un gros investissement en effort pour l’équipe mais sont essentielles pour l’utilisateur. Des groupes se forment, certains parties prenantes négocient entre elles afin d’acheter en groupe des fonctionnalités, les besoins sont ainsi mutualisés.

La première session terminée, Sacha nous explique que l’on a déjà dessiné les contours du MVP (Minimum Viable Product), c’est-à-dire l’ensemble des fonctionnalités à réaliser en priorité pour pouvoir déjà délivrer un minimum de valeur à nos utilisateurs. Comme nous n’avions pas tous dépensé tous nos billets, nous avons fait une 2ème session qui nous a notamment permis d’acheter des fonctionnalités à faible coût qui pouvaient amener rapidement un petit peu de valeur au produit, c’est ce que Sacha appelle les “quick win”.

A la fin de l’atelier, on a pu afficher au tableau toutes les fonctionnalités par ordre de priorité et nous avons travaillé ensemble pour définir des lots fonctionnels. Le but est de parcourir les fonctionnalités, de la plus prioritaire à la moins prioritaire, puis de tracer un trait quand on estime qu’on a un groupe de fonctionnalités qui sont cohérentes entre elles pour notre produit.

Sacha a conclu la matinée :

“Merci à tous pour votre participation, nous avons aujourd’hui initialisé ensemble la priorisation du backlog, il faut bien comprendre que les priorités ne sont pas immuables, ça va être désormais le rôle du Product Owner de revoir régulièrement ces priorités pour les adapter en fonction de nouveaux entrants dans le backlog, de changements de priorités liés au business ou à la réglementation.”

Le produit est désormais lancé, la Scrum team va pouvoir commencer à travailler dessus, j’ai hâte de pouvoir voir le produit se développer sous mes yeux.