D'un backlog fourre-tout à un portefeuille pilotable

Sur ma mission EDF (remplacement de la GED historique, 6 unités, ~1 000 à 1 500 personnes concernées), l’équipe avançait sprint après sprint. Mais à mon arrivée, impossible de répondre à une question pourtant simple d’un responsable : « où en est-on, et qu’est-ce qui rentre d’ici la fin de l’année ? »

La raison : un backlog où les features étaient empilées un peu au hasard. On voyait le sprint en cours, jamais le tableau d’ensemble. Voici, concrètement, comment je l’ai remis en ordre, et ce que ça a débloqué.

Le vrai problème : on ne pilote pas ce qu’on n’a pas structuré

Un backlog plat, c’est utile pour le prochain sprint et rien de plus. Pas de vision par unité, pas de macro-chiffrage, pas de planification à trois mois. Résultat : on réagit aux échéances au lieu de les anticiper, et chaque arbitrage se fait à l’instinct.

Avant de planifier, il fallait donc une structure : redonner une hiérarchie au travail déjà fait et à venir.

Étape 1 : remettre le déjà-fait en ordre

J’ai installé un outil de pilotage portefeuille (Big Picture sur Jira) et, surtout, j’ai recomposé tout l’existant dans une hiérarchie claire :

• des epics par unité : chaque unité à migrer devient une ligne de pilotage à part entière ;
• des features par grand domaine applicatif de la GED, plus la reprise de données ;
• des stories rattachées, là où elles avaient du sens.

Ce n’est pas un exercice cosmétique. C’est ce qui permet de répondre, unité par unité, à « où en est-on ».

Étape 2 : installer un langage d’estimation commun

Structurer ne suffit pas : pour planifier, il faut savoir combien pèse chaque chose. Or une grande partie des tickets n’était pas estimée. J’ai donc embarqué la tech avec moi pour estimer tout le non-estimé, et ainsi obtenir le macro-chiffrage de ce que chaque sujet avait réellement coûté.

J’insiste sur le pragmatique, parce que l’estimation est souvent mal comprise :

• On estime en story points, une mesure de complexité, d’incertitude et de volume relatif, pas en jours. Le piège classique : croire que 3 points = 3 jours. C’est faux, et le dire clairement évite des discussions stériles.
• On s’appuie sur une échelle de référence partagée (1, 2, 3, 5, 8, 13…), avec quelques tickets-repères que toute l’équipe a en tête. Tout le monde parle alors le même langage.
• La vélocité qui en découle est un outil d’aide à la planification, pas un engagement ni un indicateur de performance individuelle. Cette nuance protège l’équipe et fiabilise les prévisions.

Concrètement, estimer le travail déjà livré (par exemple le workflow de l’unité pilote, celle sur laquelle on avait fait le MVP) m’a donné des repères chiffrés solides : des features dont on connaît désormais le poids réel.

Le double bénéfice

Une fois l’existant structuré et chiffré, deux choses deviennent possibles, qui ne l’étaient pas avant :

1. Une epic par unité avec un vrai pourcentage d’avancement : un responsable voit l’état réel, pas une impression.
2. Une planification sur un Gantt où l’on vérifie noir sur blanc que « tout rentre » dans la fenêtre disponible, ou pas.

On est passé de la réaction à l’anticipation.

Ce que ça change, et ce que ça prépare

Pour un dirigeant, la différence est nette : il a enfin une vue de portefeuille fiable, pas un backlog opaque dont on extrait des promesses au doigt mouillé.

Et ces features de référence chiffrées sont aussi le carburant de l’étape suivante : elles permettent de macro-estimer le périmètre d’une nouvelle unité sans tout ré-estimer ligne à ligne. C’est l’objet d’un atelier qui a créé un vrai électrochoc côté métier. J’en parle dans l’article suivant.

C’est exactement ce que j’apporte en delivery : je structure le travail pour le rendre pilotable, j’installe les repères qui le rendent chiffrable, et je redonne à la décision une base factuelle.