Ce billet vient d’un désaccord sur twitter sur les éléments qui permettent de prioriser un backlog dans un développement agile.
On me propose de trier par valeur fonctionnelle (je vais parler de valeur ajoutée au produit, pour éviter de mélanger avec la complexité fonctionnelle) mais cela ne me convient pas.
Toutes les histoires n’ont pas le même détail
Sur mon backlog j’ai de quoi remplir plusieurs sprints. Toutes les histoires n’ont pas le même niveau de détail. Détailler tout c’est passer un temps énorme à faire un travail qui risquera d’être remis en cause et qui délaiera inutilement le développement. L’objectif n’est pas de faire un cahier des charges détaillé sur deux ans. Mon responsable produit fera ça au fur et à mesure. Ce qui est prioritaire est détaillé et plus on s’enfonce dans le backlog plus les histoires utilisateurs sont « macro ».
Une « macro » histoire sera découpée en plusieurs petites. Logiquement la valeur ajoutée liée à cette macro histoire sera aussi divisée. Si vous suivez, il y a de bonnes chances pour que les macro histoires en milieu de sprint soient celles qui ont une colonne « valeur » avec les plus gros nombres. Les histoires à faire aujourd’hui et demain seront bien découpées, et donc unitairement avec des petites valeurs ajoutées.
Voilà mon premier argument pour ne pas classer que par la valeur ajoutée : Ça reviendrait à mettre en premier les histoires les moins détaillées, puis les détailler (vu qu’elles sont prioritaires), se rendre compte que du coup d’autres sortent avant, les redétailler, et ainsi de suite. En quelques itérations on va finir par détailler trop précisément un plan d’action pour plus d’un an, et faire un travail inutile tout en ayant mal priorisé entre temps.
La priorité c’est sortir la plus grande valeur à chaque itération
Toutes les histoires n’ont pas le même niveau de détail, mais elles ne nécessitent pas toujours le même effort non plus. Imaginons un site d’actualité, avec une histoire « permettre de saisir un commentaire » (c’était impossible jusqu’alors) et une histoire « afficher le titre séparé du corps de l’article » (il était collé auparavant).
Ajouter des commentaires apporte bien plus de valeur qu’ajouter un espace entre le titre et le corps du texte, disons « 10 » pour le premier et « 2 » pour le second. Mais côté effort de développement c’est la même chose : « 20 »pour le premier, et « 0,5 » pour le second.
Si je classe simplement par la valeur ajoutée, je vais prioriser des histoires comme « saisir des commentaires ». Pourtant si je calcule j’aurai eu plus de valeur ajoutée à mon produit si j’avais priorisé d’abord plusieurs histoires de type « séparer le titre ».
Ma priorité c’est bien de livrer la plus grande valeur à la sortie de l’itération. La priorité est donc, logiquement, plus dépendante du rapport valeur/effort que de la valeur elle-même. J’ai besoin d’avoir estimé mes histoires pour en connaître l’effort et les prioriser. Un responsable produit qui priorise sans connaître l’effort associé à chaque histoire ne peut pas maximiser la valeur de son produit, et c’est pourtant tout l’objectif de la démarche.
Encore d’autres facteurs
Le ratio valeur/effort est pour moi un bon critère de tri pour la priorisation. On ajoute après des contraintes fonctionnelles comme les deadline fonctionnelles comme un contrat de partenariat à implémenter dans le mois.
Mais là aussi la technique a son mot à dire. Nos histoires ont des dépendances techniques entre elles, et ça joue et doit jouer sur les priorités. De même tout développeur sait bien que parfois faire deux tâches ensemble permet de gagner un temps certain. Il y a des priorités d’opportunité à faire : d’un coup je peux faire à moindre coup une fonctionnalité qui est normalement plus bas dans le backlog.
Parfois j’y gagne à court terme (parce que le niveau d’effort diminue tellement qu’elle devient bien prioritaire). Parfois j’y perd un peu à court terme mais je gagne bien en valeur à moyen terme puisqu’au final j’ai bien diminué l’effort et donc permis de faire une histoire de plus. Tout est un équilibre entre le gain en terme d’effort et la valeur de l’histoire à reprioriser.
11 réponses à “Priorisation du backlog”
Ça me semble assez évident de prioriser par « valeur/effort ».
Effectivement, un article de blog est beaucoup plus adapté que quelques tweets! :)
Mais même si à présent je comprends bien mieux ton point de vue, je ne suis pas totalement d’accord (mais en partie quand même! :P). Encore une fois, je précise que je suis loin (très loin) d’être un gourou de l’agilité. Je ne me base que sur mon expérience personnelle (très) limité et sur mes quelques lectures sur le sujet.Première chose, je suis tout à fait d’accord sur le fait que la technique à un minimum son mot à dire pour la priorisation. Ne serait-ce que pour prendre pleinement conscience des éventuelles dépendances entre les différentes histoires (ce n’est pas souvent qu’on emploie du vocabulaire français pour parler d’agilité! ça me plait! ^^)
En revanche, je pense que le client est le seul décideur en ce qui concerne la valeur que lui apporte telle ou telle histoire. Ce n’est pas à la technique d’en décider.
Bien entendu, cela ne signifie pas que le client possède le savoir absolu et il est impératif de pouvoir discuter avec lui des différentes histoires.
Mais pour reprendre l’exemple des commentaires et de l’espace entre le titre et le corps, même si la seconde histoire apportera plus de valeur par rapport à l’effort fourni, les commentaires apporteront plus de valeur absolue. Au client d’équilibrer la valeur de son produit avec les fonctionnalités proposées.
Même si encore une fois, le but est bien entendu d’accompagner le client.
PS: Désolé pour les modifications successives (fausse manip & corrections) :S
Ah, c’est sera toujours au responsable produit de décider la priorité, sans contestation possible sur ce point. De toutes façons tout prend en compte la valeur et *doit* la prendre en compte, donc il aura toujours la main (autant l’effort on le fait pas comparaison donc on peut le discuter, autant la valeur est toujours purement arbitraire et le responsable en fait ce qu’il veut).
L’idée c’est de lui donner les billes et un bon indicateur pour prendre la décision. Autre critère que je n’ai pas non plus pensé à mettre dans l’article : faire assez tôt les tâches « risquées » ou « pas très claires » pour avoir le temps de les travailler pas à pas au fur et à mesure des itération plutôt que de risquer de les faire trop tard et se rendre compte que ça remet tout ce qu’on a déjà fait en cause.
Je pense avoir compris l’origine de notre divergence d’opinion.
Tu utilises un nombre pour indiquer la priorité (je fais référence à la phrase « Si vous suivez, il y a de bonnes chances pour que les macro histoires en milieu de sprint soient celles qui ont une colonne « valeur » avec les plus gros nombres ») ?
Effectivement, de cette manière, une story « macro » peut potentiellement avoir une « valeur » supérieure à une story « détaillée ».
Mais de mon point de vue, donner une priorité tient plus de l’ordonnancement que de l’attribution d’une valeur et dans ce cas, la story avec la priorité la plus élevée est tout simplement la première du blacklog, et non celle avec le plus gros nombre dans la colonne valeur.
Ah, dans ce cas, la priorisation ne tient pas compte du couple « valeur/effort » mais uniquement de la valeur (perçue par le responsable produit)
Cependant, nous sommes d’accord qu’il convient d’accompagner le responsable produit durant la priorisation afin de nuancer son avis en fonction de l’effort.
Par contre je ne comprends pas vraiment la seconde partie de ton commentaire. Pour moi, le but n’est pas de commencer par les tâches les plus risquées mais bel et bien par les tâches considérées comme ayant le plus de valeur au yeux du responsable produit.
Il y a les deux. L’objectif est bien de guider par la valeur, mais l’itératif a aussi pour rôle de tester et construire au fur et à mesure. Si quelque chose risque de bousculer les développements, mettre du temps à stabiliser, ou remettre en cause ce qui est fait avant, on tente de le monter un peu plus haut pour mitiger les risques et voir le plus tôt possible si on est sur la bonne ou la mauvaise voie
Bon, je suis d’accord avec tout ça. La valeur (je parle aussi d’utilité http://www.aubryconseil.com/po… et l’effort sont des attributs qui aident à prioriser (avec le ROI valeur sur effort). Je dis aide parce qu’il y a d’autres facteurs, comme tu dis. Sur le terrain je me rends compte qu’il est très difficile d’estimer la valeur au niveau des stories. Quelques raisons : la tendance est à avoir des stories très petites, c’est bien pour planifier, mais ça rend leur valeur ténue, autre raison les stories techniques qui apportent de la valeur indirecte difficile à évaluer, les bugs dont la correction rend la valeur initiale à une story…
Le problème du ratio « valeur/effort », c’est que pour le calculer, il faut estimer l’effort sur l’ensemble des users stories ((ce qui va à l’encontre de l’agilité).
Si on ne souhaite pas tout estimer , il faut le faire sur un sous-ensemble de stories, mais comment choisir (et donc prioriser) ces stories ? c’est un peu le chat qui se mord la queue….
Tiens, j’avoue que je ne sais pas ce qu’il en est dans la littérature, mais pour moi toute fonctionnalité dans le backlog est rapidement évaluée en valeur et en effort. Les exceptions sont des choses que le responsable produit sait qu’il ne va de toutes façons pas prioriser (parce que ça se repose sur des fonctionnalités qui ne sont pas encore présentes, parce qu’il sait que la valeur est faible, ou parce qu’il se doute bien que l’effort est conséquent). Ca me semble étrange de considérer que ça va à l’encontre de l’agilité.
Par contre les estimations initiales du backlog sont très grosses mailles, pas forcément faites avec toute l’équipe, juste pour donner un ordre de grandeur. On refait ça de toutes façons quand on explose les macro histoires en plus petites, et là on joue le jeu plus complètement.
Ce que je voulais dire, c’est que les intégristes de l’Agilité vont peut être dire que toutes les stories doivent être estimées collectivement, et que ce n’est pas une personne unique qui évalue (même grosse maille), et que les estimations se font « au dernier moment », quand on en a besoin, et pas en phase amont.
Pour ma part, je n’ai pas de solutions, car j’ai déjà eu des backlogs avec un grand nombre de stories, très difficile à prioriser, et j’ai eu du mal à m’en sortir. Si des gens ont des solutions, je suis preneur !!
Ce qu’on faisait à Yahoo! et que je ne trouvais pas idiot c’était une première estimation des histoires macro par les lead tech qui permet au PO de prioriser et décider si ça vaut le coup ou pas. L’estimation fine est faite lors de la réunion de préparation de sprint avec tout le monde.
Par contre on divergeait franchement de la littérature parce que si l’input de chacun était apprécié, on affectait les tâches lors de la préparation (quitte à changer d’affectation en cours de sprint) et c’est celui qui faisait la tâche qui avait la décision sur l’estimation de sa propre tâche.
Pour le log backlog, renoncer est toujours complexe. Si tu as trop de chose il faut accepter de jeter ce qui est en bas de ton backlog, quitte à le réinscrire plus tard. Avoir des histoires pour 6 mois de dev c’est planifier à long terme et se mettre des freins au changement. Faire moins c’est s’obliger à ne pas noter dans un coin « à faire pour plus tard » et renoncer. Je n’ai pas d’astuce pour le faire.