Dans la constitution d’un Backlog, un Product Owner débutant et isolé peut vite être perdu et tenté de mesurer la valeur métier par une échelle de priorité. Une bonne façon de faire cela est de mettre une valeur arbitraire sur une User Story, disons 100, et d’évaluer la priorité des autres User Story en conséquence. Pourtant, valeur métier et priorités peuvent être liées, mais pas nécessairement. Si ce premier exercice de priorisation est un début, il doit normalement être complété d’ateliers permettant de mieux prioriser à l’aide des parties-prenantes. On pourra citer l’exemple de l’atelier Buy a Feature qui permet aux parties prenantes d’exprimer leur besoin en posant des billets de Monopoly sur une carte représentation des User Stories_.
Difficile de faire les deux ? Utiliser l’évaluation multi-dimensionnelle
Si ce genre d’atelier n’est pas organisable (certains clients considérant qu’il est difficile de lier ludisme, sérieux et concentration — ce qui est curieux mais pas à l’ordre de cette publication), il existe une autre façon de reprendre ces valorisation : l’approche multi-dimensionnelle.
L’idée est de se forcer à évaluer non pas une valeur, mais plusieurs.
Imaginons par exemple qu’on se concentre sur deux dimensions uniquement : nombre d’utilisateurs concernés et urgence de réalisation (attention : ces deux dimensions ne sont valables que dans un contexte où on estime que tous les utilisateurs apportent la même valeur et que les urgences de démarrage sont estimables).
D’un côté, on évalue la valeur métier sur, disons 5 points. De l’autre côté, on évalue l’urgence de démarrage sur 5 également. Ensuite, on établit une formule pour retrouver une note sur 100 (par exemple — (Métier×3+Urgence×2)×4 — et on compare avec la note initiale pour, si c’est pertinent, mettre à jour la « valeur projet » de la User Story.
Cet exemple s’arrête à deux dimensions, mais on peut en imaginer une troisième (les compétences disponibles, par exemple), une quatrième (les intérêts et agendas des parties prenantes présentes — ou non — aux démonstrations).
Bref, plus on décompose le problème en petites questions à se poser à soi-même (ou à l’équipe), plus on simplifie. On transforme quelque chose de compliqué en quelque chose de complexe.
Exemple de matrice de notation pour le métier
5 points
- Très important pour l’ensemble des utilisateurs
- Impact important sur la perception de la marque
- Critique pour les objectifs du projet
4 points
- Important pour de nombreux utilisateurs
- Impact significatif sur la perception de la marque
- Critique pour le fonctionnement de services spécifiques
3 points
- Important pour un nombre modéré de citoyens
- Impact modéré sur la perception de la marque
- Ne correspond pas à un service rendu
2 points
- Important pour très peu d’utilisateurs
- Dérangeant pour la perception
1 point
- Si ce n’est pas présent, personne ne s’en rendra compte
Matrice d’urgence de démarrage
5 points
- On anticipe une grosse charge
- Il s’agit d’un pré-requis fonctionnel à de nombreuses fonctionnalités
- Il faut le faire maintenant ou jamais (par exemple, une ressource clé s’en va)
4 points
- La charge est potentiellement importante
- Il s’agit d’un prérequis fonctionnel à quelques autres fonctionnalités
- Les délais d’obtention d’informations peuvent être longs
3 points
- La charge est modérée, mais glissante (il faut commencer pour lever des questions, mais les réponses pourront prendre du temps)
- Il s’agit d’une dépendance pour au moins deux autres fonctionnalités
2 points
- La charge associée est faible
- La fonctionnalité en introduit une autre
1 point
- Extrêmement rapide
- Toutes les informations sont disponibles