Regroupement

Objectif

Le regroupement transforme une longue liste d'exigences en un petit nombre de bandes prêtes pour la décision. Le problème qu'il résout est celui d'un incrément à périmètre fixe, release, timebox ou budget arrêté: l'équipe doit s'accorder vite sur ce qu'il doit contenir et sur ce qui sera coupé en premier. La priorité cesse d'être une opinion tenue en tête par chacun et devient une catégorie écrite, agréée en séance. Le jour où une exigence est repoussée, il y a une différence entre revenir sur la décision et rappeler « c'est un Should, nous l'avons décidé ensemble ».

Le regroupement est l'une des quatre approches de priorisation que le BABOK distingue, avec le classement, le time boxing et la budgétisation et la négociation. La même famille rassemble aussi des approches collaboratives comme le dot voting et le bullseye. Le regroupement apporte en propre une partition en bandes, sans ordre à l'intérieur d'une bande, à partir de définitions écrites que tout le monde lit de la même façon.

Le livrable tient dans l'outil de travail. Chaque exigence porte un attribut de priorité, sa bande, généralement un champ du carnet de produit ou du référentiel d'exigences. Le BABOK relève que beaucoup d'outils de gestion des exigences permettent d'inscrire cette catégorie comme attribut d'une exigence. L'artefact est une propriété des exigences, révisée à chaque cycle de planification.

Usage

Quand l'utiliser

• Livraison à périmètre ou budget fixe: fournir une base agréée de ce qui saute en premier si le temps manque.
• Ensemble d'exigences volumineux: un ordre total item par item coûterait plus de négociation que la décision ne le vaut.
• Besoin d'un vocabulaire d'importance partagé: remplacer le « haut, moyen, bas » que chaque partie prenante lit à sa façon.
• Exigences appelées à évoluer: faire de la priorité un attribut révisé à chaque cycle de planification.
• Plusieurs groupes de parties prenantes: obtenir vite un consensus de périmètre sans classement exhaustif de tout contre tout.

Quand ne pas l'utiliser

• Deux items d'une même bande à livrer dans un ordre précis: le regroupement ne dit pas lequel vient d'abord, prendre le classement pour séquencer.
• Plafond de ressources dur, sans marge de négociation: partir de la ressource avec le time boxing et la budgétisation, les bandes ne servant qu'ensuite de règle d'allocation.
• Désaccord de fond sur ce qui compte: le schéma de catégories n'est pas l'obstacle, mener la négociation avant de trier.

Description

Les quatre catégories et la règle qui les tient

MoSCoW range chaque exigence dans exactement une de quatre catégories, chacune portant une définition précise et convenue. L'acronyme se lit sur ses initiales, les deux o servant seulement à le prononcer.

Le Must have est non négociable. Il forme le sous-ensemble minimal utilisable. Le test tient en une question, « que se passe-t-il si ce n'est pas livré »: si la seule réponse honnête est d'annuler la livraison, c'est un Must. Le Should have est important sans être vital. Son absence fait mal sans bloquer la mise en production, parce qu'un contournement existe à court terme, une étape manuelle ou un report. Le Could have est souhaité, avec un impact nettement moindre s'il est omis. Il forme le réservoir de contingence, ce que l'on abandonne en premier dès qu'un Must ou un Should est menacé. Le Won't have this time est un report daté: l'exigence est convenue hors périmètre pour cette échéance et reste candidate au cycle suivant. Écrire ce report empêche l'exigence de resurgir et de rouvrir une discussion close.

Trier dans des bacs fixes

Le regroupement partitionne, il ne classe pas à l'intérieur d'une bande. Deux Must sont également Must, et MoSCoW ne dit pas lequel se construit d'abord. Quand la vraie question devient « lequel de ces deux Must en premier », typiquement parce que l'un dépend techniquement de l'autre, c'est le classement qu'il faut: il produit un ordre total là où le regroupement ne produit que des bandes. Les bacs sont fixes et connus d'avance, les exigences y tombent.

MoSCoW

Sur cette partition se pose une règle d'effort qui vient de DSDM et de l'Agile Business Consortium et qui n'a aucun équivalent dans le BABOK. Les Must ne devraient pas dépasser 60 % de l'effort total estimé de l'incrément, et les Could forment un réservoir de contingence d'environ 20 %. Au-delà de 60 % d'effort en Must, la prévisibilité de la livraison est compromise, sauf environnement bien maîtrisé, équipe établie et risque externe faible. Cette proportion transforme une somme de jugements individuels en un budget que l'on peut vérifier: si les Must consomment les trois quarts de l'incrément, la conclusion est que des items sont mal gradés.

Conduire le tri

1. Publier les définitions de bandes avant tout tri
   Les quatre de DSDM ou les catégories maison si MoSCoW n'est pas la convention, écrites et précises.
2. Assigner chaque exigence à exactement une bande
   Avec les parties prenantes capables de parler de la valeur métier, du risque et de l'urgence.
3. Vérifier l'équilibre d'effort après le premier passage
   Sommer l'effort estimé par bande. Si les Must dépassent nettement 60 %, des items sont surévalués et demandent réexamen.
4. Enregistrer les Won't
   Les laisser visibles pour le prochain cycle, où ils reviennent comme des décisions datées et révisables.
5. Rejouer l'assignation à mesure que le projet avance
   Le BABOK note que l'analyste revisite les priorités quand des changements surviennent.

Ce qui fait échouer l'exercice

L'inflation des Must est la défaillance la plus courante. Tout finit par être appelé Must, soit parce que les catégories ont été convenues trop mollement, soit parce que l'exigence a été énoncée à un niveau trop élevé pour être arbitrée. Le remède, tenu de la pratique DSDM, est de décomposer avant de grader. Une exigence grossière comme « consulter le solde du compte » est un Must, mais sa variante d'affichage multidevise, une fois isolée par la décomposition fonctionnelle, se révèle souvent un Should ou un Could. Un Must trop gros cache souvent des Could à l'intérieur.

Le Won't manquant est le pendant de l'inflation des Must. Les équipes gradent volontiers en Must, Should et Could mais n'assignent jamais de Won't. Les items hors périmètre restent alors dans un « peut-être plus tard » ambigu, là où le Won't en aurait fait une décision enregistrée et révisable. Une liste MoSCoW sans aucun Won't a presque toujours esquivé les choix difficiles.

Les bandes sans règle de décision sont la troisième panne. Un « haut, moyen, bas » sans test énoncé, qu'est-ce qui rend une chose haute, retombe sur le rapport de force en séance. Le BABOK, pour sa part, relève parmi les limites de la priorisation trois écueils que MoSCoW n'annule pas à lui seul: des parties prenantes qui esquivent les arbitrages difficiles; une équipe de réalisation qui surestime la difficulté d'implémentation pour peser sur la priorisation; l'absence fréquente de métriques dures, qui rend l'exercice subjectif tant qu'aucune discipline ne l'encadre. Cette discipline est la définition écrite des bandes et la vérification de l'équilibre d'effort.

Considérations IA

Le premier usage est le tri de premier jet. Un modèle de langage à qui l'on fournit le texte des exigences propose une assignation de bande pour chacune, qu'un humain confirme ou corrige. Sur un backlog de plusieurs centaines de lignes, ce triage épargne la partie la plus fastidieuse et laisse le jugement là où il compte, sur les cas litigieux.

Le deuxième usage est le plus rentable: la détection des gradations incohérentes. Deux exigences quasi identiques dont l'une est Must et l'autre Should, une exigence de valeur manifestement moindre marquée Must alors que des voisines plus fortes sont Could, le modèle repère ces contradictions à travers des centaines de lignes comme une salle ne le fera jamais. Il calcule de même la somme d'effort par bande et signale quand les Must franchissent le seuil de 60 %.

Ce que l'IA ne doit pas faire tient à la nature de la bande. La valeur métier d'une exigence est une décision de partie prenante ancrée dans un contexte que le modèle n'a pas: une exposition réglementaire, une sensibilité politique, un engagement pris envers un client précis. Un modèle ne peut pas être l'auteur unique d'un verdict Must, Should, Could ou Won't que l'on traiterait ensuite comme convenu, parce que toute la valeur de MoSCoW est l'accord humain derrière l'étiquette. Une bande produite par la machine et adoptée sans séance est une étiquette sans engagement. Enfin, un backlog charrie souvent des informations stratégiques sensibles, une tarification non annoncée, des fonctionnalités non divulguées, si bien que le confier à un outil externe est une décision de traitement des données.

Exemples

Une caisse-maladie de Suisse romande prépare la prochaine release de son portail d'assurés en libre-service, un incrément à budget fixe de CHF 180'000 sur douze semaines.

Le simulateur de prime est un Could, le premier candidat à l'abandon si un Must dérape, parce que le portail reste utilisable sans lui. Le chatbot figure dans la liste comme Won't have this time, une décision datée de le reporter, et l'avoir écrit évite qu'il ne resurgisse dans trois semaines comme une demande neuve à réarbitrer. Si l'estimation montrait ensuite que les deux Must consomment les trois quarts des douze semaines, ce serait le signal de rouvrir leur découpage plutôt que de rogner sur les Should, conformément à la règle des 60 %.

Visualisations

La liste des bandes est faite de lignes et de colonnes. Inscrit en HTML, l'attribut de bande se trie, se filtre, se compte par formule et se recopie dans l'outil de backlog, ce qu'une image de tableau interdit. La bande porte une définition écrite lisible sur l'artefact, le Won't figure au même titre que les trois autres bandes, et chaque exigence occupe exactement une ligne dans une seule bande.

Le mécanisme du tri, lui, ne rentre pas dans un tableau, parce qu'il tient à des positions et à des proportions. Il se dessine: un lot d'exigences entrant, quatre bacs fixes et étiquetés qui les reçoivent et le budget d'effort rendu visible par la taille des bacs: au maximum 60 % pour les Must, une réserve d'environ 20 % pour les Could. Cette vue distingue le regroupement de ses voisins d'un coup d'œil, là où le classement alignerait une seule file ordonnée et où le time boxing partirait d'un contenant de taille fixe.

Coût

Outils

Tout outil de gestion des exigences ou de backlog qui accepte un champ personnalisé ou une étiquette de priorité convient, de Jira à Azure DevOps en passant par un catalogue d'exigences ou une simple feuille de calcul partagée. Il n'y a pas lieu d'en recommander un: l'important est que la bande soit un attribut de l'exigence elle-même, révisé avec elle.

La feuille de calcul mérite une mention à part. L'équilibre d'effort y devient une formule: une colonne d'effort estimé, une somme par bande, une cellule qui vire au rouge dès que la part des Must dépasse 60 %. La vérification que la technique demande à chaque passage se fait alors toute seule, à l'instant où le tri est saisi. Les mêmes formules repèrent les gradations suspectes et comptent combien d'items chaque bande retient. Un outil de backlog place la bande là où l'équipe lit déjà et la versionne, ce qui répond à la défaillance d'entretien la plus banale, une priorité posée une seule fois et jamais reprise. L'outil à éviter est la diapositive: une liste MoSCoW dans une présentation est la photographie d'un arbitrage, elle ne se trie pas, ne se recompte pas et se périme dès la première réestimation.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.33 Prioritization: le regroupement comme l'une des quatre approches de priorisation, l'exemple générique « haut, moyen, bas », l'inscription de la catégorie de priorité comme attribut d'une exigence, la révision des priorités quand des changements surviennent et les limites reconnues de la priorisation, arbitrages esquivés, difficulté d'implémentation surestimée et rareté des métriques dures. Cité de façon descriptive: le BABOK ne définit ni les catégories MoSCoW ni la règle d'effort.
• Agile Business Consortium, MoSCoW Prioritisation, DSDM Project Framework: les définitions des quatre catégories, Must have comme sous-ensemble minimal utilisable, Should have, Could have comme contingence et Won't have this time comme report daté, ainsi que l'équilibre d'effort: un plafond de 60 % pour les Must et une réserve autour de 20 % pour les Could. C'est la source de toutes les règles opérationnelles de MoSCoW.
• Dai Clegg et Richard Barker, Case Method Fast-Track: A RAD Approach, Addison-Wesley / Oracle, 1994: l'origine de MoSCoW, forgé par Dai Clegg puis adopté par le consortium DSDM. Cité pour ce seul fait historique, les règles opérationnelles courantes relevant de la publication actuelle de l'Agile Business Consortium.