Business : que doit éviter un Product Owner?

Seul le Product Owner peut le gérer

Malheureusement, il existe un grand malentendu parmi de nombreux propriétaires de produits concernant la gestion du backlog. Un Product Owner est responsable du Product Backlog, ce qui signifie que les Product Owners en sont responsables. Cependant, cela ne signifie pas qu’ils sont les seuls à pouvoir insérer de nouveaux éléments dans le backlog de produit.

Un Product Owner doit encourager l’équipe Scrum et les parties prenantes à créer de nouveaux éléments de carnet de produit. Le framework Scrum favorise la collaboration. Par conséquent, les propriétaires de produits ne peuvent pas être les seuls à gérer le BacklogBacklog. Une fois que de nouveaux éléments de carnet de produit arrivent, nous, en tant que propriétaires de produits, devons plutôt les comprendre, les affiner et les commander de manière appropriée.

Individus et interactions sur les processus et les outils

– Manifeste Agile

Les antécédents du propriétaire du produit peuvent être à l’origine de ce malentendu courant. Par exemple, dans les méthodologies traditionnelles, les exigences ne sont pas gérées de manière collaborative, principalement les analystes l’écrivent. Cependant, cela ne justifie pas que le Product Owner ne s’adapte pas pour collaborer davantage avec tout le monde, de sorte qu’un meilleur backlog de produit puisse être établi.

Il existe de nombreuses raisons différentes à la naissance de ce mythe. Une cause fréquente est le fait que les propriétaires de produits agissent à titre d’analystes (commerciaux) ou prennent leur place dans ce contexte. De ce point de vue, il peut sembler judicieux pour eux de s’occuper de l’ensemble de «l’analyse des exigences» nécessaire pour remplir un carnet de produit. Souvent, les équipes de développement encouragent cela afin qu’elles puissent se concentrer sur ce qu’elles supposent être leur tâche la plus importante: écrire du code. Mais ce n’est pas ainsi que les rôles sont prévus.

– Christiaan Verwijs, Mythe: le Product Backlog est géré exclusivement par le Product Owner

Anciens éléments du carnet de produits

Un carnet de produit est un artefact vivant, ce qui signifie que les propriétaires de produits doivent le consulter en permanence. Pourtant, je suis tombé sur des scénarios dans lesquels le Product Backlog contient des éléments de plus de deux ans. Alors je demande:

Si l’élément de carnet de produit se trouve dans le carnet de commandes pendant deux ans, quelle est la valeur de cet article?

Je suis fermement convaincu que les anciens éléments doivent être supprimés du carnet de produits pour éviter le gaspillage. Une fois que nous ne les avons pas, nous n’avons plus besoin de nous embêter. La question est, comment gérer ce scénario? Je ne garde pas les articles de plus de trois mois. Je supprime du Product Backlog tous les éléments antérieurs à cette période. Depuis que j’ai commencé à suivre cette approche, j’ai senti que nous devenions une équipe plus productive et plus efficace.

Le carnet de produits contient des éléments qui n’ont pas été touchés depuis six à huit semaines ou plus. (Il s’agit généralement de deux à quatre sprints. Si le propriétaire du produit accumule des éléments de backlog, le risque émerge que les anciens éléments deviennent obsolètes, rendant ainsi obsolète le travail précédemment investi de l’équipe Scrum.)

– Stefan Wolpers, 28 Arriéré de produits et anti-modèles de raffinement

Les articles du Product Backlog deviennent périmés comme le lait si vous gardez les anciens articles en vie. Finalement, vous devez en parler. Très probablement, vous décidez de les garder commandés plus bas dans le Backlog Produit. Alors pourquoi ne pas le retirer? Ne vous passionnez pas pour les éléments du carnet de produit, rappelez-vous, Scrum consiste à inspecter et à adapter.

Franchissez des frontières différentes

Le Scrum Guide souligne, le Product Backlog répertorie tout ce qui concerne le développement de produits; Pourtant, de nombreuses équipes décident de le diviser en technique et en fonction Product Backlog. La division de l’arriéré de produits est une énorme erreur. Il n’y a qu’un seul backlog de produit.

Pourquoi l’arriéré de produits multiples est-il un problème? La collaboration est considérablement réduite; les silos deviennent une réalité. Un scénario problématique courant consiste à diviser l’arriéré de produits en technologie et en affaires. Dans ce cas, un désalignement est inévitable entre le Product Owner et l’équipe de développement, ce qui entraîne des inconvénients importants pour l’ensemble des performances Scrum.

Il n’y a qu’une seule équipe Scrum; ils sont responsables de tout ce qui concerne le développement de produits. Ensemble, ils doivent trouver un moyen de gérer et de commander le Backlog Produit. Le Product Owner doit fournir la vision du produit, afin que l’équipe puisse comprendre les défis techniques qui peuvent survenir; en tant qu’équipe unique, un Product Backlog est créé.

Maintenance peu fréquente

Comme je l’ai mentionné précédemment, le Product Backlog est un artefact vivant. Même si nous savons que le carnet de produit n’est jamais terminé, j’ai vu de nombreuses équipes investir peu de temps dans le raffinement des éléments du carnet de produit. Cette approche est un anti-modèle, que nous devons éviter.

En ne faisant pas suffisamment de sessions de raffinement du carnet de produit, l’équipe Scrum rate une chance d’inspecter et d’adapter. Nous devons accepter que nous ne savons pas tout pour atteindre notre objectif; par conséquent, nous devons continuer à affiner les éléments du carnet de produit, afin de pouvoir inspecter et adapter au besoin.

Le Scrum Guide suggère que le Backlog Refinement ne consomme généralement pas plus de 10% de la capacité de l’équipe de développement. Mon approche est, dans un Sprint de deux semaines, j’investis 1h30min dans le Backlog Refinement, cela fonctionne bien, mais vous devez évaluer ce qui correspond le mieux à votre scénario.

L’affinement du carnet de produit est l’acte consistant à ajouter des détails, des estimations et de l’ordre aux articles du carnet de produit. Il s’agit d’un processus continu dans lequel le propriétaire du produit et l’équipe de développement collaborent sur les détails des éléments du carnet de produit. Pendant le raffinement du carnet de produit, les éléments sont examinés et révisés. L’équipe Scrum décide comment et quand le raffinement est effectué. Le raffinement ne consomme généralement pas plus de 10% de la capacité de l’équipe de développement. Cependant, les éléments du carnet de produit peuvent être mis à jour à tout moment par le propriétaire du produit ou à sa discrétion.

– Le guide Scrum

Plus de raffinement

Un autre anti-modèle consiste à affiner trop d’éléments de carnet de produit. Il est essentiel de garder à l’esprit que le Product Backlog est une liste ordonnée, où les éléments supérieurs sont plus détaillés que les éléments inférieurs.

Une fois que nous tombons dans ce piège, nous avons tendance à avoir trop planifié d’avance. Cependant, une planification trop avancée génère du gaspillage, car au fur et à mesure que nous sprintons, nous en apprenons davantage, ce qui signifie que les éléments de backlog de produit inférieurs peuvent être affinés ou même devenir obsolètes. Par conséquent, nous devons affiner les éléments sur le dessus; puis, tout en continuant à apprendre, nous affinons les autres éléments. Plus l’élément est bas, moins nous en savons.

Simplicité – l’art de maximiser le montant
de travail non effectué – est essentiel.

– Manifeste Agile

Un excellent article de carnet de produit démarre une conversation. Le but de cette conversation est d’établir une compréhension commune. Il est impossible de décrire parfaitement ce que vous voulez construire. Le mieux que vous puissiez faire est d’essayer de mettre tout le monde sur la même longueur d’onde et de parvenir à un consensus dans leur esprit.

– Maarten Dalmijn, les grands propriétaires de produits écrivent des éléments de carnet de commandes affreux

Énorme

Certains propriétaires de produits qui passent d’une méthodologie traditionnelle à une autre ou qui viennent de la gestion de projet ont tendance à trop planifier. Dans l’approche Waterfall, les exigences sont toutes définies à l’avance. De plus, les exigences sont généralement caractérisées par une seule personne ou une équipe distincte, ce qui signifie que l’équipe n’est pas impliquée.

Dans Scrum, nous devons accepter que nous ne connaissons pas notre chemin depuis le début. Nous savons où nous voulons aller, mais le chemin que nous découvrons dans l’expérience et l’apprentissage. Rappelez-vous, Scrum est empirique; plus nous marchons, plus nous en savons.

L’empirisme affirme que la connaissance vient de l’expérience et de la prise de décisions basées sur ce qui est connu.

– Le guide Scrum

Attention, ne transformez pas votre Scrum en cascade!

L’équipe Scrum crée un backlog de produit couvrant le projet ou le produit complet dès le départ car la portée de la version est limitée. (Question: comment pouvez-vous être sûr de savoir aujourd’hui quoi livrer dans six mois?)

– Stefan Wolpers, 28 Arriéré de produits et anti-modèles de raffinement

Emballer

La gestion du backlog produit est une activité commune, tout le monde y collabore. Une gestion de backlog de produit réussie doit avoir les caractéristiques suivantes:

• Les propriétaires de produits encouragent tout le monde à produire de nouveaux éléments de carnet de produit.
• L’affinement du Backlog produit se produit aussi souvent que nécessaire.
• Les éléments de plus de trois mois sont supprimés sans discussion.
• Il existe un seul backlog de produit.
• Seuls les éléments en haut du Backlog sont affinés.
• Il n’y a pas de planification initiale; nous acceptons que nous ne connaissons pas tout le chemin.

Voulez-vous écrire pour Serious Scrum ou discuter sérieusement de Scrum?