Feuille de route produit

Objectif

La feuille de route produit est le document où une organisation lit en une page ce qu'elle veut que son produit devienne, dans quel ordre et avec quelle certitude. Chaque ligne est un thème, soit un ensemble de fonctionnalités ou d'exigences qui servent un même résultat attendu; chaque colonne est une tranche de temps. L'Agile Extension lui donne pour finalité de communiquer la direction prise vers la vision de la solution et de mesurer l'avancement vers cette vision par l'atteinte des résultats attendus des parties prenantes.

Les équipes tiennent chacune leur backlog, la direction tient ses objectifs annuels, le service commercial promet des fonctionnalités en rendez-vous client. Rien ne rapproche ces trois listes. La question qui revient en séance, « quand aurons-nous cette fonctionnalité? », reçoit alors une date inventée par celui qui répond. La feuille de route substitue à cette date une position sur un axe et un degré de certitude qui décroît avec la distance.

Elle sert une seconde décision, que le guide énonce: l'obtention du budget de livraison. Un comité qui finance un produit sur plusieurs exercices arbitre sur des résultats attendus et sur leur ordre, matière qu'une liste de tickets ne lui donne pas. La feuille de route est le support de cet arbitrage, puis la référence sur laquelle il se révise; le business case instruit ensuite chaque thème pris isolément.

Le livrable est la feuille de route, tenue à jour, accompagnée du registre des résultats attendus et de leurs mesures. Le guide place la technique à l'horizon Stratégie, le plus large des trois horizons de l'Agile Extension.

Usage

Quand l'utiliser

• Plusieurs équipes sur un même produit: une direction unique remplace autant de plans que d'équipes.
• Demande de budget pluriannuel: le comité arbitre sur des résultats attendus et sur leur ordre.
• Vision arrêtée, chemin encore ouvert: l'ordre des thèmes se fixe sans figer les solutions.
• Parties prenantes qui réclament des dates: les tranches de temps donnent une réponse tenable et discutable.
• Produit vendu à des clients externes: une vue publique annonce la direction sans engager de version.
• Demandes concurrentes venues de plusieurs services: les thèmes les rendent comparables sur le résultat visé.

Quand ne pas l'utiliser

• Vision remise en cause à chaque comité: le document se périme avant d'être lu; le travail à conduire porte d'abord sur la vision elle-même.
• Engagement contractuel sur des dates et un périmètre: un échéancier et une estimation engageante répondent à la demande.
• Une équipe, un produit, un horizon de trois mois: la gestion du backlog suffit à tenir l'ordre.

Description

Deux formats pour un même contenu

Une feuille de route prend deux formes et l'Agile Extension emploie les deux sans les distinguer. Son texte décrit des fonctionnalités exprimées en « maintenant, ensuite, plus tard »; sa figure 7.10.1 pose une grille de quatre trimestres où chaque capacité occupe une case, l'une d'elles découpée en trois segments répartis sur le premier, le deuxième et le quatrième. Le choix entre ces deux formats fixe ce que le lecteur pourra exiger.

Le format calendaire découpe l'axe en trimestres ou en semestres. Il se lit sans explication par un comité habitué aux exercices budgétaires et s'aligne sur le cycle de financement. La barre de largeur variable, à cheval sur deux colonnes de l'échelle, vient de Lombardo, McCarthy, Ryan et Connors, dont Product Roadmaps Relaunched fixe la forme de référence.

Le format maintenant, ensuite, plus tard découpe l'axe en trois volets de certitude décroissante. Le premier est engagé et financé, le deuxième est cadré sans être ordonnancé, le troisième est une intention que la prochaine mesure peut renverser. Aucune colonne ne porte de date et le comité perd son repère budgétaire.

Les deux formats portent le même contenu. Le passage des trimestres aux trois volets ne perd rien; l'inverse oblige à poser des dates. Le format calendaire est le seul que le guide illustre.

Feuille de route produit

Le même contenu, en trois volets

Les éléments

La vision et la stratégie ouvrent le document. La vision dit ce que la solution couvre et le résultat qu'elle vise; c'est elle que le guide charge de clarifier ce qui entre dans le périmètre. La stratégie dit par quel chemin l'organisation compte y arriver. Une liste des demandes écartées, tenue à côté du document, nomme ce que l'organisation renonce à faire. Un partenaire ou un client cherche cette seconde liste autant que la première.

Les résultats attendus sont énoncés pour l'organisation et pour les parties prenantes. Lombardo et ses coauteurs font du résultat mesuré l'ossature du document: un résultat se formule avec sa mesure, son point de départ et sa cible, « part des ouvertures de compte réalisées sans passage en agence, de 12% à 45% ». La mesure permet de constater après coup si le thème livré a produit ce qu'on en attendait. Sans elle, un thème reste une intention et son avancement se rapporte en pourcentage de code écrit.

L'équipe de gestion du produit tient le document. Le guide la décrit petite, conduite par le product owner ou par un représentant des clients. Il lui confie trois obligations: refléter les priorités du moment, rester accessible à ceux qui en ont besoin, adapter la vue selon l'audience. Cette équipe est le propriétaire nommé; sans ce nom, la révision s'arrête au deuxième trimestre.

Les thèmes sont les lignes. Un thème regroupe des exigences, des fonctionnalités ou des user stories qui servent un même résultat. Lombardo et ses coauteurs le font nommer par ce résultat: « ouvrir un compte sans passer en agence » tient sur une ligne et parle à un comité.

Les exigences de haut niveau remplissent les thèmes. Chacune regroupe des exigences ou des stories dont l'équipe de livraison tirera son backlog. Leur granularité décroît avec l'éloignement: un thème du volet engagé se décrit en trois ou quatre éléments nommés, un thème lointain tient en une phrase.

Le cadre SAFe distingue la feuille de route d'incrément de programme, celle du produit ou de la solution et celle du portefeuille, chacune tenue par un organe différent et couvrant une durée différente. La feuille de route produit correspond au niveau produit ou solution; la vue de portefeuille relève du Portfolio Kanban, qui montre à quelle étape chaque initiative engagée se trouve.

Comment la construire

L'ordre compte: chaque étape prend en entrée le produit de la précédente. On écrit d'abord la vision en une phrase qu'un tiers peut contester. On énonce ensuite les résultats attendus, trois à six, chacun avec sa mesure, son point de départ relevé et sa cible.

On regroupe alors les demandes existantes, backlog, tickets de support, engagements commerciaux et obligations réglementaires, en les rattachant chacune à un résultat. Une demande qui ne se rattache à aucun résultat pose une alternative: soit le résultat manque à la liste, soit la demande sort du produit. On ordonne les thèmes obtenus, par la priorisation ou par un vote pondéré du comité, et on les place sur l'axe choisi.

Reste à fixer la cadence de révision et le nom de la personne qui tient le document. Une révision par trimestre, avant l'arbitrage budgétaire, suffit à la plupart des produits. La feuille de route porte sa date de révision en clair, ce qui évite qu'une copie vieille de neuf mois circule comme si elle valait encore.

Une feuille de route, plusieurs vues

Le guide compte la vue par audience parmi les forces de la technique: direction, équipe de livraison et clients externes lisent le même document à trois niveaux de détail. Les trois vues se dérivent d'une source unique. Entretenues en parallèle, elles divergent en un trimestre et l'organisation se retrouve avec trois directions.

Ce qui fait échouer la technique

Le trimestre lu comme une date

L'engagement sur des dates lointaines est le premier mode d'échec que Lombardo et ses coauteurs documentent, et le guide énonce la même limite: la technique se détourne en calendrier de jalons. Un thème posé sur le troisième trimestre devient « livré en septembre » dans le compte rendu, puis un engagement dans un courrier client. Deux ajouts au document limitent la dérive: une mention du degré de certitude par colonne et la date de dernière révision. Le troisième correctif est une pratique: la première révision qui déplace un thème d'un trimestre à l'autre, faite devant le même comité, apprend au lecteur ce que vaut un placement.

La vision qui change tous les mois

Le guide donne la technique pour inefficace là où la vision et les résultats attendus se rediscutent à chaque comité. La feuille de route y est refaite plus souvent qu'elle n'est lue, parce que la cause est en amont du document et qu'aucun format ne la corrige.

Le détail qui rend la maintenance impossible

Le guide signale le coût d'entretien d'une feuille de route trop détaillée ou déclinée en trop de vues. Un thème tient sur une ligne et se lit à trois mètres du mur. Dès qu'une ligne porte une liste de tickets, le contenu appartient au backlog et la feuille de route a commencé à le dupliquer. Au-delà de trois vues, une équipe de gestion de produit de deux ou trois personnes ne suit plus.

Le thème nommé par le composant

« Migration vers la nouvelle passerelle de paiement » nomme un chantier interne. Le comité ne sait pas l'arbitrer, faute de résultat auquel le comparer, et il l'accepte ou le refuse sur la réputation de celui qui le présente. Le même travail, nommé « payer sans quitter l'application » et assorti d'une mesure, entre dans la comparaison avec les autres thèmes.

Considérations IA

Un modèle de langage sert cette technique sur le volume. Sur un export de backlog et de tickets de support, il propose des regroupements par intention et fait apparaître les thèmes candidats, travail qu'une équipe conduit sinon en atelier sur plusieurs demi-journées; la proposition se relit, mais elle part d'une matière que personne n'aurait lue en entier. Il repère les thèmes dépourvus de mesure, les mesures dont le point de départ n'est pas renseigné et les demandes rattachées à aucun résultat. Il compare deux versions successives de la feuille de route et liste ce qui a bougé, ce qui prépare l'ordre du jour de la révision. Il décline une vue de direction en vue client à partir de la même source, en retirant ce qui ne doit pas sortir, sous relecture.

L'ordre des thèmes ne se demande pas à un modèle. Il dépend d'engagements déjà pris, d'un rapport de force entre services, d'une échéance réglementaire et de la capacité des équipes, dont aucun n'est écrit dans le document soumis. Le placement sur une colonne relève de la même limite: un modèle sommé de dater un thème produit un trimestre plausible sans capacité derrière. Les cibles des résultats attendus se négocient avec ceux qui devront les tenir. Une feuille de route porte des entrées de marché non annoncées, des noms de fournisseurs et des enveloppes budgétaires: ces éléments se retirent avant tout envoi vers un modèle public.

Exemples

L'équipe de gestion du produit d'une banque cantonale tient la feuille de route de son application mobile, revue chaque trimestre par la direction des services aux particuliers. Le format est le format calendaire à quatre trimestres.

Feuille de route produit

Banque cantonale, application mobile

Quatre thèmes portent quatre résultats et les barres ne s'alignent pas. L'ouverture de compte avance en deux étapes sur les deux premiers trimestres; le conseil en ligne dans le cadre de la LSFin tient sur le deuxième; le paiement occupe une barre à cheval sur le deuxième et le troisième, puis reprend au quatrième; l'épargne n'apparaît qu'au quatrième, à l'état de pilote. Cette irrégularité est ce qu'une feuille de route donne à voir: les thèmes ont des tailles différentes et la certitude tombe vers la droite.

Le registre des résultats se tient à côté de la feuille de route. C'est lui que le comité relit à chaque révision, thème par thème.

La colonne du départ est celle qui manque le plus souvent. Un point de départ relevé transforme la révision suivante en constat vérifiable.

Visualisations

La feuille de route se dessine en lignes et en colonnes: une ligne par thème, portant en tête son résultat et sa mesure, une colonne par trimestre. Chaque barre couvre les trimestres que le thème occupe, l'une d'elles pouvant déborder d'un trimestre sur le suivant. Un dégradé ou un contour plus léger sur les colonnes de droite rend visible la certitude décroissante. La date de dernière révision et le nom de l'équipe qui tient le document figurent sur la figure elle-même, puisque c'est elle qui circule.

Le format à trois volets se dessine en trois colonnes de cartes, sans échelle de temps, la colonne de gauche seule portant du détail. Le registre des résultats se lit en tableau, une ligne par thème.

Coût

Outils

Le mur reste l'outil de la séance de construction: des colonnes tracées au ruban adhésif, une carte par thème, un déplacement possible pendant la discussion. Il suppose une équipe réunie au même endroit et ne produit rien qui circule.

Les tableaux blancs collaboratifs (Miro, Mural et leurs équivalents) tiennent le même rôle pour une équipe répartie sur plusieurs sites. Ils conviennent mal à la diffusion, parce que le lecteur occasionnel n'ouvre pas un tableau sans limites pour y chercher une ligne.

Le tableur et la présentation portent la majorité des feuilles de route en service. Ils produisent une vue de direction lisible en une diapositive, à un coût nul. Leur défaut est la copie: une diapositive part par courriel, perd sa date de révision et circule ensuite pour elle-même. Verrouiller la date de révision dans le pied de page limite les dégâts.

Les outils de gestion de produit (ProductPlan, Aha!, Roadmunk, Jira Product Discovery et leurs équivalents) rattachent les thèmes aux items du backlog et produisent plusieurs vues à partir d'une source unique, ce qui répond à la limite d'entretien. Ils se paient par utilisateur et demandent que le backlog soit déjà propre.

Reste l'outil dont dépend la mesure: le système qui produit les indicateurs, mesures d'usage du produit ou tableau de bord décisionnel. Un résultat attendu que personne ne sait mesurer chaque trimestre laisse la feuille de route sans moyen de constater son propre effet.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.10 Product Roadmap: la finalité de la technique, les cinq éléments, dont l'équipe de gestion du produit et les thèmes, les forces énoncées, dont les vues par audience, les trois limites et le placement à l'horizon Stratégie. La figure 7.10.1 donne le format calendaire, une grille de quatre trimestres où chaque capacité occupe une case.
• C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors, Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty, O'Reilly Media, 2017: la feuille de route comme énoncé de direction, le format construit sur les résultats attendus et sur une échelle de temps, la barre de largeur variable à cheval sur plusieurs colonnes, le thème nommé par son résultat, ainsi que les modes d'échec documentés, au premier rang desquels l'engagement sur des dates et des fonctionnalités lointaines.
• Scaled Agile Framework, Roadmap: la déclinaison de la technique sur plusieurs niveaux, celui de l'incrément de programme, celui du produit ou de la solution et celui du portefeuille.