Ordre vs Priorité

Il y a parfois des conversations au sein des équipes à propos de la responsabilité de la priorisation des éléments du backlog.

Le problème est surtout le résultat de cette conversation. Quiconque aura la responsabilité de cette priorisation, que ce soit le Product Owner, ou que ce soit un agrément au sein de l’équipe, nous aurons un résultat qui ressemblera à :

• 80% des éléments en priorité 1
• 15% en priorité 2
• 5% en priorité 3

Cela génère des discussions sans fin pour déterminer ce qui peut être priorité 1, 2 ou 3, et cela n’aide pas réellement à décider par quoi l’on doit commencer la première itération, quel sera le sens de celle-ci, et quel pourrait être le sens de la prochaine version marketing.

A l’approche de la date prévue pour la version marketing, les personnes commencent à s’inquiéter de savoir si tous les éléments de priorité 1 vont bien pouvoir être inclus dans la version. Soudainement la définition de la priorité 1 devient : « doit être dans la version », et les personnes se trouvent focalisés sur ce qui ne va pas être inclus, plutôt que sur ce qui pourrait l’être.

C’est la raison pour laquelle j’essaie d’éviter le mot priorité et que je demande plutôt dans quel ordre les éléments doivent ils être livrés. Je m’intéresse à l’ordre des éléments pour ceux qui pourraient être inclus dans les 2 prochaines itérations. Et je m’intéresse à savoir quel sens cela aura pour le produit et pour les utilisateurs.

A un plus haut niveau, il pourrait être intéressant de donner un vue globale du sens des prochaines versions, et des itérations de la prochaine version. Ce n’est pas un priorité, c’est une séquence, un ordre.

Cela veut dire également que l’on a besoin d’un outil pour enregistrer cet ordre. Un mur avec des post-it peut enregistrer cela. La plupart des outils de gestion de tâches/projets ne le peuvent pas.

La photo d’entête est de Ryan McGuire.