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

Sur quels critères baser 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.

Voir aussi