Prio­ri­sa­tion du back­log


Ce billet vient d’un désac­cord sur twit­ter sur les éléments qui permettent de prio­ri­ser un back­log dans un déve­lop­pe­ment agile.

On me propose de trier par valeur fonc­tion­nelle (je vais parler de valeur ajou­tée au produit, pour éviter de mélan­ger avec la complexité fonc­tion­nelle) mais cela ne me convient pas.

Toutes les histoires n’ont pas le même détail

Sur mon back­log 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 inuti­le­ment le déve­lop­pe­ment. L’objec­tif n’est pas de faire un cahier des charges détaillé sur deux ans. Mon respon­sable produit fera ça au fur et à mesure. Ce qui est prio­ri­taire est détaillé et plus on s’en­fonce dans le back­log plus les histoires utili­sa­teurs sont « macro ».

Une « macro » histoire sera décou­pée en plusieurs petites. Logique­ment la valeur ajou­tée liée à cette macro histoire sera aussi divi­sé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écou­pées, et donc unitai­re­ment avec des petites valeurs ajou­tées.

Voilà mon premier argu­ment pour ne pas clas­ser que par la valeur ajou­tée : Ça revien­drait à mettre en premier les histoires les moins détaillées, puis les détailler (vu qu’elles sont prio­ri­taires), se rendre compte que du coup d’autres sortent avant, les redé­tailler, et ainsi de suite. En quelques itéra­tions on va finir par détailler trop préci­sé­ment un plan d’ac­tion pour plus d’un an, et faire un travail inutile tout en ayant mal prio­risé entre temps.

La prio­rité c’est sortir la plus grande valeur à chaque itéra­tion

Toutes les histoires n’ont pas le même niveau de détail, mais elles ne néces­sitent pas toujours le même effort non plus. Imagi­nons un site d’ac­tua­lité, avec une histoire « permettre de saisir un commen­taire » (c’était impos­sible jusqu’a­lors) et une histoire « affi­cher le titre séparé du corps de l’ar­ticle » (il était collé aupa­ra­vant).

Ajou­ter des commen­taires apporte bien plus de valeur qu’ajou­ter 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éve­lop­pe­ment c’est la même chose : « 20 »pour le premier, et « 0,5 » pour le second.

Si je classe simple­ment par la valeur ajou­tée, je vais prio­ri­ser des histoires comme « saisir des commen­taires ». Pour­tant si je calcule j’au­rai eu plus de valeur ajou­tée à mon produit si j’avais prio­risé d’abord plusieurs histoires de type « sépa­rer le titre ».

Ma prio­rité c’est bien de livrer la plus grande valeur à la sortie de l’ité­ra­tion. La prio­rité est donc, logique­ment, plus dépen­dante du rapport valeur/effort que de la valeur elle-même. J’ai besoin d’avoir estimé mes histoires pour en connaître l’ef­fort et les prio­ri­ser. Un respon­sable produit qui prio­rise sans connaître l’ef­fort asso­cié à chaque histoire ne peut pas maxi­mi­ser la valeur de son produit, et c’est pour­tant tout l’objec­tif de la démarche.

Encore d’autres facteurs

Le ratio valeur/effort est pour moi un bon critère de tri pour la prio­ri­sa­tion. On ajoute après des contraintes fonc­tion­nelles comme les dead­line fonc­tion­nelles comme un contrat de parte­na­riat à implé­men­ter dans le mois.

Mais là aussi la tech­nique a son mot à dire. Nos histoires ont des dépen­dances tech­niques entre elles, et ça joue et doit jouer sur les prio­ri­tés. De même tout déve­lop­peur sait bien que parfois faire deux tâches ensemble permet de gagner un temps certain. Il y a des prio­ri­tés d’op­por­tu­nité à faire : d’un coup je peux faire à moindre coup une fonc­tion­na­lité qui est norma­le­ment plus bas dans le back­log.

Parfois j’y gagne à court terme (parce que le niveau d’ef­fort dimi­nue telle­ment qu’elle devient bien prio­ri­taire). Parfois j’y perd un peu à court terme mais je gagne bien en valeur à moyen terme puisqu’au final j’ai bien dimi­nué l’ef­fort et donc permis de faire une histoire de plus. Tout est un équi­libre entre le gain en terme d’ef­fort et la valeur de l’his­toire à reprio­ri­ser.


11 réponses à “Prio­ri­sa­tion du back­log”

  1. 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

  2. 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.

  3. 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.

  4. 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.

  5. 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

  6. 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…

  7. 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….

  8. 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.

  9. 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 !!

  10. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.