Portfolio backlog – la proposition de SaFe

Il est parfois nécessaire d’utiliser un portfolio backlog quand une entreprise travaille sur des besoins imposant l’utilisation de plusieurs équipes à sa réalisation. Safe Framework fait une proposition qu’il est intéressant de regarder ; même des équipes en agilité à l’échelle qui n’ont pas décidé d’appliquer Safe peuvent être intéressées.

Qu’est ce que le Portfolio backlog ?

Le Portfolio Backlog est un système Kanban utilisé pour capturer et gérer les Business Epics et habilitantes destinées à créer et à faire évoluer les produits, services et solutions du portefeuille (portfolio).

En Safe, le Portfolio Backlog est géré par le Lean Portfolio Management (LPM) qui est responsable du développement, de la maintenance et de la hiérarchisation du carnet de commandes du portefeuille.

Création et Affinage du portefeuille

Le LPM applique une approche basée sur les flux pour créer et affiner le backlog, garantissant que les epics du portefeuille sont prêts à être mis en œuvre avec un niveau approprié de découverte et de risque.

Affiner le backlog du portefeuille pour assurer la préparation implique souvent les activités suivantes :

• Examiner les nouveaux epics et déterminer leur alignement avec les thèmes stratégiques et la vision du portefeuille.
• Évaluer l’ Epic Hypothesis Statement pour décider si il justifie une affectation à un Epic Owner.
• Prioriser le backlog en utilisant Weighted Shortest Job First (WSJF) et d’autres facteurs en collaboration avec les propriétaires d’entreprise, les architectes d’entreprise, la gestion des produits et d’autres parties prenantes

Les activités de l’affinage du backlog se produisent souvent pendant les événements Portfolio Sync et Strategic Portfolio Review.

Le LPM et ses parties prenantes ajoutent de nouveaux éléments de backlog à l’entonnoir, mettent à jour les priorités et suppriment les épopées moins prometteuses. Un carnet de commandes bien entretenu est une condition préalable à une gestion de portefeuille réussie.

Gestion du portfolio backlog avec Kanban

Voici l’image proposée par Safe pour présenter un board kanban représentant la gestion de ce portefeuille général du programme :

Le système Portfolio Kanban visualise et facilite le flux de Business Epics, de l’idée à la mise en œuvre. Grâce à cette transparence, le développement et les avancées du programme dans sa globalité sont visibles et bien plus simple à gérer de façon « macro ».

D’ailleurs ce Porfolio kanban permet également de mettre en avant la phase d’analyse amenant à la décision importante d’implémenter ou non chaque Business Epic. En effet, en avançant sur le projet, peut être que certains Business Epics ne seront plus nécessaires ou n’apporteront pas autant de valeurs que prévu. Cette agilité est nécessaire dans la priorisation afin de rester concentrer sur la valeur à délivrer.

Le Funnel

Le funnel (entonnoir) est utilisé pour recueillir toutes les idées commerciales et technologiques importantes pour un portefeuille spécifique. Ces idées peuvent provenir de préoccupations stratégiques, émaner d’équipes agiles ou d’ART, ou de suggestions de clients et de partenaires. Ces idées devraient être suffisamment importantes pour insérer ce board.

Les Epics sont à la base décrites dans l’Epic Hypothesis Statement. Le Funnel n’est pas limité au WIP car ces Epics sont simplement des idées qui peuvent mériter une considération supplémentaire. Si l’examen initial d’une idée n’est pas susceptible de dépasser le seuil épique ou de constituer un problème de portefeuille, il passe à l’ART ou au Solution Train Kanban. Bien qu’elles puissent provenir de n’importe quelle source, l’image ci-dessous illustre la façon dont les épopées s’écoulent généralement dans le Funnel :

• le maintien de la vision et de la feuille de route du portefeuille identifie de nouvelles initiatives qui alimentent directement le portefeuille Kanban. Ces initiatives peuvent inclure des mises à jour de la stratégie d’entreprise ou soutenir d’autres portefeuilles.
• le processus d’exploration continue découvre les besoins des utilisateurs et du marché et peut aboutir à l’identification d’Epics.

Reviewing

Étant donné que les Epics font partie des investissements de portefeuille les plus importants, un Epic Owner est nécessaire pour parrainer l’Epic et définir son intention. Lorsqu’un Epic Owner est disponible, il tire l’Epic dans cet état, en travaillant avec les parties prenantes concernées pour affiner et élaborer davantage l’Epic Hypothesis Statement.

Une limite WIP pour cet état est généralement spécifiée. De plus, l’absence d’un Epic Owner disponible pour effectuer le travail peut servir de limite implicite WIP. Une estimation WSJF relative à d’autres éléments dans l’état d’examen est établie sur la base d’estimations préliminaires de dimensionnement et de coût. Supposons que l’Epic ne semble pas suffisamment viable ou alignée sur les thèmes stratégiques du portfolio backlog ou d’autres garde-fous. Dans ce cas, il passe à l’état Terminé, ce qui libère de la capacité pour des alternatives plus prometteuses.

Ready

Les Epics dans l’état d’analyse avec le WSJF le plus élevé sont transférées dans l’état suivant, « Ready », dès que de l’espace est disponible. Cet état est un état d’attente à faible coût où les épopées sont périodiquement examinées et hiérarchisées en mettant à jour WSJF et d’autres facteurs pertinents

Implementing

Étant donné que de nombreuses entreprises génèrent plus de bonnes idées qu’elles ne peuvent en financer, le LPM et les participants de différents flux de valeur déterminent en collaboration quels Epic doivent être mis en œuvre sur la base du Participatory Budgeting (PB) ou d’un processus similaire. Les résultats de l’événement PB fournissent des feedback pour aider le LPM à décider comment ajuster les budgets de flux de valeur pour soutenir la mise en œuvre des Business Epic et habilitantes les plus bénéfiques.

La mise en œuvre des Epic inclut également des considérations pour le séquencement du travail, le dimensionnement et le classement des Epic les uns par rapport aux autres, généralement par une hiérarchisation finale WSJF (Weighted Shortest Job First). Des ajustements à la priorité épique du WSJF peuvent être nécessaires pour rester dans les garde-fous du budget Lean, tels que l’allocation des capacités, les horizons d’investissement et d’autres facteurs. Le LPM doit avoir une bonne compréhension de la capacité de l’ART disponible, car la durée du travail utilisée par WSJF peut être affectée par la capacité de mise en œuvre.

L’Epic Owner travaille avec diverses parties prenantes pour diviser les epics en fonctionnalités et capacités. Les ART et Solution Trains responsables placent le travail dans leurs backlogs respectifs, comme illustré dans l’image ci-dessous :

Lorsqu’elles sont prêtes à être mises en œuvre, les fonctionnalités et capacités sont présentées lors des PI Planning pertinents pour commencer le développement du MVP de l’Epic. Le LPM évalue les progrès du MVP sur la base d’indicateurs avancés, de KPI Value Stream et de démos.

L’étape de mise en œuvre comporte deux sous-états, MVP et Persevere.

MVP

Lorsqu’une capacité suffisante d’un ou plusieurs ART est disponible, les epics avec le WSJF le plus élevé passent à l’état MVP. Ici, le propriétaire Epic travaille avec les équipes agiles pour commencer les activités nécessaires au développement du MVP et évaluer son hypothèse de résultat commercial. Le travail sur le MVP se poursuit jusqu’à ce que l’argent alloué au MVP ait été dépensé ou que l’hypothèse puisse être évaluée.

Si le flux de valeur manque d’argent pour mettre en œuvre le MVP et que le besoin de l’Epic existe toujours, un nouveau peut être proposé et placé dans le Funnel L’Epic original passe lui à Done. Bien sûr, le LPM peut adapter cette règle (et toutes les autres) pour répondre aux besoins de son organisation.

Persevere

Si l’hypothèse s’avère vraie, l’Epic passe à l’état Persevere (persévérer) et les équipes continueront à implémenter des fonctionnalités et des capacités supplémentaires. Les ART gèrent l’investissement supplémentaire via la hiérarchisation continue des fonctionnalités dans le ART backlog dans divers flux de valeur. Finalement, l’Epic sera « suffisamment faite » pour que le WSJF en cours accorde la priorité aux nouvelles capacités et fonctionnalités d’autres sources. Les propriétaires d’Epic restent disponibles pour aider les ART et les Solution Trains responsables de la mise en œuvre.

Done

Un Epic est considéré comme terminé lorsqu’une connaissance ou une valeur suffisante est atteinte, ou qu’elle n’est plus une préoccupation du portfolio. Remplir le périmètre entièrement envisagé à partir du Lean business case n’est pas un critère. Au lieu de cela, l’Epic est Terminé si :

• Il est éjecté du Portfolio Kanban par le LPM dans l’un des états précédents
• L’hypothèse est prouvée et le LPM a déterminé qu’une gouvernance de portefeuille supplémentaire n’est plus nécessaire

Si l’hypothèse est prouvée, travaillez sur l’Epic peut se poursuivre par les différentes ART chargées de sa mise en œuvre. L’Epic Owner peut avoir besoin de fournir des conseils et un suivi continus. Étant donné que l’Epic n’est plus une préoccupation du portfolio, des indicateurs avancés, des KPI de flux de valeur et des garde-fous sont utilisés pour tenir le LPM informé des progrès.

Cet article utilise l’article original de Safe : Article