Backlog : critères pour établir les priorités

Un des points forts de Scrum est le backlog de produit, qui regroupe toutes les exigences, ce qui facilite leur gestion. Il est -techniquement- simple de définir les priorités entre les éléments du backlog. Mais sur quels critères se baser ?

Il faut d'abord bien comprendre que la priorité correspond à l'ordre de développement. Ce ne sont pas 2 notions différentes. La priorité est souvent comprise autrement -que pour définir le contenu des itérations-(voir ce billet précédent), tant qu'on n'a pas pratiqué Scrum.

Sur quels critères baser les priorités ?

Il y a sur ce sujet une différence entre les approches type UP (RUP et OpenUP) et les approches agiles (Scrum).

  • Dans les premières, le contenu des itérations est guidé par les risques. Au début d'un projet, ce sont essentiellement les risques techniques liés à l'architecture. C'est donc l'architecte qui aura une voix prépondérante pour définir les priorités.
  • Dans les secondes on évoque principalement la valeur pour le client. C'est le product owner qui fixe les priorités.

Dans la pratique, je conseille de tenir compte de la position dans le cycle de vie :

  • se baser sur les risques notamment techniques au début d'un projet,
  • lorsque les principaux risques ont été réduits, de passer aux choix du product owner, basés sur la valeur apportée.

Un bon product owner fixe les priorités en :

  • s'appuyant sur les dépendances entre les exigences. Par exemple dans une application de gestion des changements, on va logiquement développer la soumission du changement avant son analyse,
  • sachant que la valeur n'est vraiment obtenue que lorsque le produit est déployé (mis en production).

Ajouté le 26 novembre

Les dépendances dont je parle sont des dépendances "métier", qui sont assez naturelles. Ce qu'il faut éviter c'est que des dépendances techniques influent sur les priorités, après réduction des risques.

Commentaires

1. Le vendredi 03 novembre 2006, 12:45 par Stéphane

Je comprend pourquoi la priorité et l'ordre de developpement sont forcement identiques..
Lors du Sprint Planning, il y a doit bien avoir concilliation entre le Product Owner (valeur métier) et l'equipe (contraintes techniques/architecturales) non?


Claude : Lors de la réunion de planification du sprint, la discussion (conciliation) peut amener à ajuster les priorités. Mais je pense qu'il est préférable -quand c'est possible- de tenir compte des contraintes d'architecture avant de lancer les sprints, lors de la préparation de la release. Cela permet de ne faire que des ajustements limités à chaque début de sprint, lors des réunions de planification.

2. Le samedi 04 novembre 2006, 03:14 par Oaz

Un "pur" agiliste serait tenté de dire que l'architecture n'est jamais que le plus haut niveau de conception qui, dans une modèle parfait, va émerger de la réponse au changement (feedback->ajout fonctionnel->refactoring...) et que, donc, l'équipe n'a pas vraiment à négocier la prioritisation par rapport à des contraintes techniques puisque celles-ci peuvent être résolues a posteriori.
Mais y-a-t-il des personnes pour se risquer à faire systématiquement ce pari là ?

3. Le samedi 04 novembre 2006, 03:20 par Oaz

En ce qui concerne la problématique des dépendances entre les exigences, je crois que le sujet déborde du cadre de la prioritisation.
Une question plus fondamentale me semble être : quel est le meilleur moyen pour exprimer des exigences ?
UP et certaines méthodes agiles (XP) se rejoignent d'ailleurs un peu sur ce point là. En XP, le problème ne se pose pas car les histoires utilisateur sont entièrement indépendantes. Les cas d'utilisation de UP s'orientent (dans une certaine mesure) dans cette même direction d'indépendance.


Claude : Je ne crois pas que les histoires utilisateur puissent toujours être complètement indépendantes. Je reprends le cas d'un logiciel qui gère les changements (un bug tracker). Une demande de changement passe par de nombreux états. Si on ne veut pas avoir de dépendances entres des histoires (ajouter avant analyser), cela revient à ne faire qu'une seule histoire utilisateur pour toute la gestion de la demande de changement, ce qui donne une histoire trop grosse pour être finie en une itération.
4. Le dimanche 05 novembre 2006, 15:03 par Le Francoué

Ca me fait penser à une technique de prioritisation qui s'appelle 'requirement value analysis' utilisée dans les grands systèmes. On fait évaluer la valeur ajoutée des exigences par le client et en parallèle la complexité (mélange de risque et de cout) de réalisation (équipes technique).
Cela donne un facteur de priorité qui est utile lorsque le délai de mise sur le marché du produit (time to market) est prépondérant. On décide de réaliser les exigences qui apporteront le plus de valeur ajoutée dans un délai adéquat. En cas de problème ou de risque, on est à même de décider ce qui ne sera pas mis sur le marché pour la première version du produit.

5. Le vendredi 10 novembre 2006, 21:27 par Oaz

Le problème avec l'exemple du bug tracker c'est de savoir si un cas d'utilisation 'soumettre un bug' seul apporte vraiment de la valeur au client ? En d'autres termes, le logiciel lui servirait-il à quelque chose si un scénario issu de ce cas d'utilisation était implémenté sans rien d'autre qui lui permette de visualiser les bugs saisis ?

Comme le dit Cockburn dans un de ses papiers sur les use cases alistair.cockburn.us/inde... : The level of greatest interest is the user goal, the goal of the primary actor trying to get work done. This corresponds to what might be called "user task", or "elementary business process". A user goal addresses the question: "Does your job performance depend on how many of these you do today?"

Pour moi, un cas d'utilisation "soumettre un bug" ne passe pas le test parce que ce n'est pas un but en soi. Par contre "soumettre un ensemble de bugs et obtenir une liste de tous les bugs soumis" le passe car c'est un but, certes simplifié, que l'on peut avoir pour effectuer une revue de la qualité d'un produit -- revue pour laquelle on se sert de ce bug tracker.
Si un tel scénario ne tient pas dans une itération, on a effectivement un problème mais je ne crois pas que ce soit le cas, quel que soit l'environnement utilisé pour l'implémentation.


6. Le samedi 11 novembre 2006, 00:56 par claude aubry

Tout d'abord je ne parle pas de cas d'utilisation. Ce que dit Cockburn, appelé aussi test "du chef" par Larman, s'applique aux cas d'utilisation. Les histoires utilisateur ne sont pas des cas d'utilisation.

Cependant une des qualités d'un bonne histoire est d'apporter de la valeur, aussi. Pour revenir à mon exemple, l'histoire utilisateur qui a pour titre "soumettre un bug" a comme condition de satisfaction (critères de test) quelque chose comme "le bug est ajouté à la liste des bugs déjà soumis". Vous avez pu penser, à tort, que l'histoire s'arrêtait avant. Cela montre bien que le titre de l'histoire ne suffit pas pour être compris, que la conversation fait partie de l'histoire et qu'il est utile, comme je l'ai dit dans un précédent billet, de définir les critères de test d'une histoire. Cela précisé, je crois que nous serons d'accord.

Pour revenir au début du débat portant sur la dépendance entre histoires d'utilisateur, mon propos est de dire qu'il y a une dépendance entre l'histoire "soumettre un bug" et l'histoire "analyser un bug soumis", ce qui implique naturellement que la première soit plus prioritaire que la seconde. Quelle valeur aurait "analyser" s'il n'y avait pas de bug soumis ?

7. Le dimanche 12 novembre 2006, 22:35 par Oaz

'Quelle valeur aurait "analyser" s'il n'y avait pas de bug soumis ?'

J'ai envie de répondre par une pirouette : si une histoire n'a pas de valeur, pourquoi la proposer ?
C'est ce que je tente d'expliquer dans mon billet en rétrolien. Il est inutile de construire des dépendances entre les histoires pour gérer une planification. Si on se contente de proposer les histoires ayant le plus de valeur, cette planification se réalise automatiquement.

8. Le dimanche 12 novembre 2006, 23:22 par claude aubry

Hello Oaz. Votre position est basée sur la définition des priorités en considérant la planification d'une seule itération, celle qui commence. Le billet que j'ai écrit -mais ce n'est peut-être pas très explicite- est une réflexion sur les critères de priorité pour planifier une release, c'est à dire plusieurs itérations, en tous cas au moins les 2-3 à venir. Dans ce cas, l'objectif est d'ordonner tous les items du backlog et les dépendances que j'évoquais sont utiles (leur construction n'est pas difficile et n'est faite qu'une fois)

Pas le temps de lire votre billet en rétrolien maintenant, il est trop long.

9. Le lundi 13 novembre 2006, 23:07 par Oaz

Je suis tenté de demander "pourquoi planifier 2 itérations à l'avance ?"
Les enseignements que l'on va tirer de l'itération en cours ne sont même pas encore connus !

Ceci étant dit, il faut tout de même faire le choix des priorités pour l'itération à venir immédiatement. Et là, bien sûr, on a besoin d'une sorte de relation de dépendance.
Ce que j'essaie de mettre en évidence, c'est que je vois plus cette relation dirigée par la valeur ("Quelle histoire puis-je raconter et prioritiser qui va me permettre d'obtenir un système immédiatement confrontable à la réalité d'un modèle métier ?") que par des dépendances fonctionnelles ("Quelle histoire est réalisable sans avoir besoin de dérouler auparavant une autre histoire ?")

10. Le jeudi 16 novembre 2006, 18:20 par claude aubry

Hello Oaz, merci pour les commentaires même si nous avons parfois un peu de mal à nous comprendre...

Pour continuer le débat, je ferai un nouveau billet sur les 2 niveaux de planification : à court terme, c'est un plan d'itération, mais il arrive, souvent d'après mon expérience, qu'on ait également besoin d'une planification à plus long terme, qu'on qualifie de plan projet ou, comme je l'ai repris de Mike Cohn, plan de release.

La discussion continue ailleurs

1. Le dimanche 12 novembre 2006, 22:30 par L'Agilitateur

Exprimer ses besoins

Il y a quelques temps, dans un billet sur la qualité, j'ai mentionné le rôle que joue l'expression des besoins dans la réalisation d'un produit de qualité. J'y racontais comment les pratiques de XP on...