Une problématique récurrente de la construction d’un backlog agile est d’établir des priorités entre les sujets (features, use cases,..) pour être en capacité de remplir nos futurs sprints, sur la base d’une évaluation partagée avec le métier, les utilisateurs, les besoins IT, les contraintes techniques, etc…
Il y a de nombreuses méthodes pour y parvenir, la plus courante est d’organiser une “session de priorisation” sous forme d’un atelier avec plus ou moins de flou dans l’argumentation des participants (chacun défendant les sujets qui lui semble important), hiérarchiser et ordonnancer les idées de sujets à traiter par l’équipe. La première erreur est de ne pas convenir des règles d’évaluation très en amont.
1ère erreur : ne pas valider son cadre de notation en amont (anticiper)
Les critères de notation des sujets doivent s’appuyer sur une grille d’évaluation qui aura été établi en amont des ateliers. Votre produit ou projet doit répondre à des attentes. Ces objectifs sont sa raison d’être et, même si il peuvent évoluer, sont la base sur laquelle vous devez établir vos critères de priorités.
Vos principes de base pour prioriser devraient dans un premier temps venir de vos enjeux (voir mon article sur les enjeux). Le but est ici de poser le cadre général ; votre terrain de jeu futur. Cet échange sur les priorités de votre produit ou projet doit être effectué au plus tôt (lors du cadrage du projet par exemple) et surtout, il a lieu en général dans un contexte plus global et donc non corrélé à des cas d’usage spécifique qui feront l’objet de débats enflammé en atelier, vous devez identifier et partager votre entonnoir de décision :
Une fois le cadre général posé et validé par toutes les parties prenantes, de manière neutre, vous disposerez ainsi de critères de tri des besoins “hérités” de décisions prises en amont et si possible approuvés par la plus haute autorité décisionnelle sur le sujet. Sponsor, directeur,… lors d’un comité stratégique ou de pilotage où vous les aurez présentés.
Tout besoin qui ne répondra pas à ces attentes sera déjà plus complexe à faire passer “en force”. À défaut il sera clairement identifié comme tel par tous les acteurs. Un participant aura ainsi plus de difficulté à contourner le cadre ainsi posé, même si vous ne pourrez pas toujours l’éviter : utilisez cet écart comme argument de retour à la raison ou pour faire ajuster les enjeux globaux.
2e erreur : Ne pas tester ses critères
Après avoir établi vos critères avec les différentes parties prenantes (sponsor métier, IT, utilisateurs référents, équipe produit), vous devez impérativement expérimenter la viabilité de votre grille de tri des idées de besoins et sujets en cours.
Ainsi vous disposez d’une grille avec 4,5 voire 10 critères grand maximum et chacun est pondéré sur l’ensemble en terme d’importance :
Prenez par exemple la liste des objectifs qui ont permis le financement des travaux (ou du projet) avec les principaux risques identifiés et passez le tout “à la moulinette” de votre grille d’évaluation. Ce sera encore mieux si vous avez pu identifier une série d’EPIC, User Stories (US) et tâches plus ou moins significatives. Si le résultat ne vous semble pas cohérent (cela se verra très vite) : ajuster vos coefficients.
3e erreur : Savoir inclure et exclure certaines thématiques
Un débat fréquent concerne les contraintes réglementaires, légales (RGPD, mise en application d’une loi, alignement sur une directive sanitaire ou RH) ou en termes de sécurité. Vu leur importance on veut les mentionner, ne pas les oublier (en particulier si votre RSSI, DPO ou service juridique est dans les débats).
Ma préconisation est la suivante : Il faut isoler ces critères (problématiques liés à la conformité ou aux contraintes légales). On les mentionne mais pour info, car de toute façon on risque de devoir les faire dans les délais impartis à la contrainte qu’ils portent.
Si vous devez mettre à jour votre référentiel comptable pour la nouvelle année, que cela impacte l’ensemble des projets de l’entreprise et porte donc un risque sur le calcul de son bilan, atterrissage financer etc.. Vous devrez être prêt avant le 31 décembre! donc planifions ce sujet en conséquence mais ne l’intégrons pas au autres qui n’ont pas ces impératifs.
Par contre pensez à inclure les contraintes IT : faisabilité, intégration aisé au SI, alignement avec la feuille de route d’architecture du SI, traitement de l’obsolescence, etc.. Il faut que toutes les parties prenantes y retrouvent de quoi valoriser leurs demandes, notamment ceux qui développent vos logiciels, et que la dette technique ne soient pas oubliée.
Aller plus loin : Comment prioriser et structurer un backlog