Partie intégrante de la vie d’un projet, la priorisation permet de trouver un juste équilibre entre les contraintes business et les enjeux technologiques à un instant donné afin de mettre rapidement en production un produit de qualité.

PRIORISATION = F(BUSINESS, TECHNOLOGIE)

Cela revient à s’assurer que l’on travaille toujours sur ce qui est important ou opportun, et éviter de passer du temps sur des sujets inutiles ou secondaires. C’est aller chercher en permanence l’apport de valeur pour le produit en s’assurant de la construction pertinente de son produit.

1 - Pourquoi prioriser ?

On s’en doute, la priorisation n’est pas une activité neutre. Elle commence dès les premiers instants du projet et est nécessaire jusqu’aux derniers. La priorisation nous oblige en permanence à se projeter dans le futur, à anticiper l'enchaînement des développements, à prévoir l’impensable et surtout la manière d’y remédier.

Les intérêts de la priorisation sont multiples. Les exercices de priorisation permettent d’identifier certains risques du projet (coûts, délais, dépendances, ressources, etc), de vérifier que l’ordonnancement des tâches est conforme à la vision du produit et à la logique de développement. Enfin, c’est surtout une projection dans le futur qui permet d’avoir les deux ou trois coups d’avance nécessaires au bon déroulement du projet.

Prioriser, c’est donc optimiser notre capacité à faire et faciliter la planification de nos tâches et de nos livraisons. On gagne aussi à mieux maîtriser la communication autour du produit. Dans bien des cas, il n’est pas possible de s’y soustraire : on priorise des tâches parce que nous avons beaucoup de demandes et une capacité de traitement moindre.

2 - Les critères de la priorisation

L'environnement des projets peut s’avérer complexe. Sortir un nouveau produit (construit de toutes pièces ou enrichi sur une base existante) nécessite l’élaboration d’une stratégie de delivery dont la priorisation est une composante majeure.

On peut distinguer cinq critères principaux de priorisation: le business, la technologie, les contraintes externes, les risques projets et les imprévus. La priorisation est pertinente si TOUS les critères sont pris en considération.

En fonction de la phase de votre projet (produit en construction ou produit en enrichissement), certains critères ont plus de poids que les autres. Prenons l’exemple d’un produit en construction. Bien que le produit ou la feature soit très attendus par les clients, les choix technologiques sont plus importants pour la fiabilité et la durabilité du projet (ie. technologie du socle, choix de stacks technologiques). A l’inverse, dans le cadre d’un produit enrichi, c’est peut-être plus les attentes du marchés (comprendre le besoin en nouvelles fonctionnalités) qu’il faut prendre en considération. Ces deux exemples démontrent que les critères de priorité peuvent être pondérés différemment en fonction de la phase de notre projet.

Nous ne parlerons pas ici explicitement du temps. Le temps, tout le monde court après. Il en manque toujours et c’est en permanence que qu’il faut jouer avec la montre.

A. Le critère de la valeur ajoutée

Le contexte business est le critère majeur qui impose un rythme aux choix de priorités. A certaines périodes, il peut y avoir des échéances business fortes sur certaines fonctionnalités. L’entreprise peut s’être engagée auprès de ses utilisateurs à livrer une  fonctionnalité clé avant une certaine date. La priorisation doit donc prendre en compte le “Time-to-market”.

Et de façon générale, il est d’usage de prioriser les fonctionnalités qui vont apporter le plus de valeur aux utilisateurs - ou celles qui par effet “Waouh” offrent un impact d’image positif - et de réserver les fonctionnalités “nice to have” pour des livraisons futures.

Quand le produit sera disponible aux utilisateurs (early adopters ou non), les retours qu’ils pourront vous faire nous amèneront à modifier notre priorisation. Sans pour autant se laisser diriger par les retours des utilisateurs, il est important de prendre en compte des remarques sur le produit que plusieurs pourront partager.

B. Le critère technologique

Il arrive dans certains projets que les développeurs n’aient pas leur mot à dire concernant la priorisation. C’est dommage car ils sont les plus à même pour identifier les éventuels quick-wins. D’autant que parfois, nous n’avons pas le choix : techniquement certaines fonctionnalités ont  plus de sens à être développées avant d’autres (ie. développer une API avant un front).

Nous étudions ici les contraintes qu’impose une dette technique abyssale, la refonte de briques techniques obsolètes ou inadaptées. Monter des étages sur un immeuble sans fondations est stupide, c’est pourquoi il est intéressant de s’attaquer aux bases (le socle technologique, les choix architecturaux) de notre produit avant de vouloir développer de nouvelles fonctionnalités. De surcroît, le choix de certains technologies seront nécessaires à votre incrément de valeur.

Dans cette prise en compte des contraintes technologiques, il faut évaluer le temps de réalisation. Cette contrainte temporelle nous amènera sûrement à revoir vos choix, au moins dans un premier temps. On visera, par exemple, un MVP sur une feature pour proposer rapidement de la valeur, et faire des choix plus conséquent pour fiabiliser technologiquement la feature. Il faut viser le bon équilibre et abuser de bonne intelligence.

C. Les contraintes externes

Un autre levier décisif pour la priorisation est la prise en compte des contraintes externes.

Il arrive régulièrement qu’un développement soit repoussé à plus tard car il nécessite la disponibilité d’une brique technique extérieure fournie par un partenaire (exemple : service de paiement). L’intérêt est de développer en premier les fonctionnalités qu’on pourra terminer plutôt que d’en réaliser une partie et d’attendre que les contraintes externes se lèvent.

Outre les questions de dépendances, d’autres contraintes peuvent obliger à prioriser certains développements. Il peut s’agir de contraintes d’ordre technique - par exemple la sortie d’une nouvelle version d’iOS nécessitant de passer du temps pour vérifier si le code actuel est compatible - ou d’ordre réglementaire - comme devoir ajouter certains champs pour être conforme aux normes Bâle 2 (domaine bancaire) ou encore ergonomique - comme pour se rendre conforme aux règles d’accessibilités suite à un audit de certification.

D. Les risques projet

Stratégiquement, nous voulons réaliser tout ce qui comporte des risques le plus tôt possible dans les projets, afin d’avoir la confirmation que les risques ont été éliminés.

Pour les risques métier, on va tester au plus tôt les fonctionnalités structurantes sur des populations réduites d’utilisateurs afin de recueillir leurs feedbacks et éventuellement changer son fusil d’épaule s’il s’avère que les utilisateurs ne sont pas intéressés.

On va aussi tester rapidement les pré-requis élémentaires du produit. Par exemple, pour un site e-commerce, il vaut mieux se rendre compte le plus tôt possible qu’on ne pourra pas s’interfacer avec le service de paiement.

Pour les risques techniques le but est à peu près le même. L’idée est de dérisquer au plus tôt l’ensemble des appels à un SI par exemple afin de pouvoir trouver des solutions palliatives en cas de problème.

E. Les imprévus

On priorise tout au long du projet, et il est important de noter que même s’il existe peu de risques dans le projet, il y aura toujours des imprévus qui vont nous forcer à re-prioriser :

la visite de tel sponsor projet auquel on a promis de faire une démonstration sur telle fonctionnalité, le marché qui évolue d’une manière inattendue., etc. Tout peut remettre en cause une partie de votre proposition de valeur. L'habileté et la confiance de l’équipe permet de pallier ces situations, toujours frustrantes.

3. En bonus

Conséquence directe d’un exercice de priorisation, certaines user stories bien qu’intéressantes, d’un point de vue business ou technologique, seront mises de côté ou reportées à une date ultérieure. La différences par rapport au autre US du backlog ? Ces US sont nice to have, pas forcément difficile à réaliser et l’on peut être tenter de les supprimer du backlog. Ce paquet d’US constitue le Stock Biz au sein du backlog et il est intéressant de les conserver.

On peut ainsi profiter de creux de business - pendant la période estivale par exemple - pour consacrer quelques itérations à optimiser l’application en développant des fonctionnalités moins essentielles : on piochera alors dans les US du Stock Biz.

Mais aussi, d’un point de vue tactique, il peut être intéressant de choisir de confier certaines de ces US “nice to have”, simples à réaliser, aux membres récemment arrivés dans l’équipe pour leur permettre de se “faire la main” sur le code de l’application.

C’est pourquoi il est intéressant de toujours garder de côté dans le backlog un stock de fonctionnalités non prioritaires, sans toutefois tomber dans l’obésité du backlog : des user stories qui ne seront jamais réalisées seront simplement supprimées du backlog.

4. Posture pour prioriser

La priorisation est un jeu avec lequel il faut être à l’aise. Il suppose d’avoir en permanence la vision du produit, et la vision de l’avancement de son projet. La mise en production d’un produit n’est pas une promenade de santé. Tout est fait, selon la loi de Murphy, pour nous retarder, faire changer vos plans, etc.

A. Communiquer

La priorisation, bien que souvent portée par le product owner, n’est pas à son usage exclusif. Seul, il ne pourra pas prioriser de manière intelligente. Il a besoin de son équipe, et des décideurs sur le plan technique et sur le plan fonctionnel. C’est bien de cette interaction entre les acteurs clés du produit (product owner, techlead, utilisateurs finaux, etc) que peut surgir une priorisation partagée et efficace.

B. Décider

La revue des priorisations, c’est comme ressentir des turbulences sur un vol au long court. L’idéal, c’est de les éviter, quoique imprévisibles. La confiance de l’équipage et son expérience permettent de mieux appréhender ces phases de vols. Et comme un bon pilote, il faudra savoir s’adapter. Certaines situations seront trop dangereuses, il faudra alors apprendre à dire NON. NON car trop de risques, trop de délais, trop d’incertitude, etc.

C. Négocier

Les enjeux parfois sont tels que nous ne pourrons pas faire autrement que de répondre d’une manière ou d’une autre au besoin qui nous est demandé. S’il n’est pas possible de dire NON, il faut alors se donner une marge de manoeuvre pour réussir : c’est la négociation. La nouvelle demande implique forcément du temps ou des ressources en moins pour finir ce qui a été engagé sur le sprint. Négocier le délai, renégocier le périmètre du sprint, etc. Belle partie de poker en perspective pour trouver un consensus qui satisfasse l’équipe, l’utilisateur et qui réponde toujours aux enjeux attendus par le produit.

D. Protéger

Une des grandes attentes d’une priorisation bien huilée est de maintenir la stabilité de l’équipe. C’est le point intangible. Faire en sorte que la trajectoire de l’avion soit la plus confortable possible, la plus douce, la plus calme. Si la priorisation doit remettre en cause la sécurité de l’équipe ou du projet, le plus sage est encore de refuser une demande, ou de la négocier. Quelle que soit la situation, les décideurs (fonctionnels ou techniques) prendront des décisions franches, après avoir étudié et pris en compte les contraintes et arguments de chacun des acteurs.

Pour conclure

Prioriser suppose de trouver un juste équilibre entre les impératifs à court terme de l’équipe (métier et développeurs) et des contraintes externes, le tout dans une stratégie plus long terme basée sur les risques et les éventuelles opportunités tactiques d’optimisation.

La phase du produit (construction ou enrichissement) nous aidera à pondérer vos critères de priorisation. On reprécise bien ici que la priorisation ne peut pas se faire sur la base d’un seul de ces cinq critères, mais que c’est bien l’ensemble de ces indicateurs qui nous permettront d’être efficace dans votre priorisation.

Une bonne priorisation suppose également de faire discuter tous les acteurs pour trouver des compromis : c’est la communication puis la négociation. Et cette négociation intervient principalement dans les séances de backlog grooming que nous organisons régulièrement au cours de notre projet. Elles permettent de rassembler les acteurs clés du produit, sans oublier les utilisateurs finaux, pour partager les contraintes et trouver la bonne priorisation.

Malgré tous les critères possibles, la priorisation est le fruit des attentes business et des choix technologiques. Prioriser, et surtout reprioriser en permanence, est au cœur des pratiques agiles. C'est parce qu'elle est en capacité de s'adapter et de réagir rapidement (de changer ses priorités) qu'une équipe est agile. Elle atteint alors un état de résilience parfait où elle sait gérer les turbulences sans délai et de manière continue.

PRIORISATION = F(BUSINESS, TECHNOLOGIE)