Le backlog de produit est un outil simple mais puissant pour capturer et réviser les décisions détaillées sur les produits et diriger le travail de l’équipe de développement. Malheureusement, l’utilisation efficace de l’arriéré peut être difficile. Cet article traite de sept erreurs courantes du backlog de produit pour vous aider à les reconnaître et à les corriger.
Le carnet de produit est trop important Il y a quelques années, on m’a demandé d’aider une entreprise de santé dans sa transition agile et son impact sur la gestion des produits. L’un des défis qui préoccupait l’équipe de transition agile était le choix du bon outil de backlog de produit, ce qui au début m’a semblé étrange. Mais quand on m’a dit que le backlog en question comptait plus de 40 000 éléments, j’ai pu voir qu’il y avait un problème.
Certes, c’est de loin le plus gros backlog de produits que j’ai rencontré à ce jour. Mais je trouve qu’il n’est pas rare de rencontrer des arriérés allant de plusieurs centaines à quelques milliers d’éléments. Mais un tel carnet de produit est difficile à appréhender, encore moins à hiérarchiser et à mettre à jour. Cela est problématique, en particulier pour les produits jeunes et ceux qui connaissent un changement plus important, comme une extension du cycle de vie , car leurs carnets de commandes ont tendance à être volatils et nécessitent des ajustements fréquents et parfois plus importants. Vous devez donc vous efforcer de garder votre carnet de produit aussi concis que possible chaque fois que votre produit est confronté à des incertitudes et à des changements, qu’ils soient liés au marché, à l’entreprise ou à la technologie.
La formation product owner pole emploi permet à toutes personnes souhaitant devenir product owner de se lancer et de passer, grâce aux cours product Owner de passer la certification PSPO1.
Les trois techniques suivantes vous y aideront : Tout d’abord, regroupez les éléments connexes en thèmes. Deuxièmement, gardez les éléments de moindre priorité à grain grossier. Troisièmement et surtout, concentrez le backlog sur un objectif de produit spécifique . Ensuite, refusez et supprimez les éléments qui ne servent pas cet objectif, comme je l’explique ci-dessous. Le carnet de produit est trop détaillé Une autre fois, on m’a demandé d’aider une équipe d’une grande organisation caritative au Royaume-Uni dont la tâche était de créer un nouveau site Web pour leurs campagnes de collecte de fonds.
La formation agile product owner, est la solution idéale permettant de passer la certification PSPO1.
Le product owner m’a dit qu’elle avait affiné le backlog du produit du mieux qu’elle pouvait, mais que l’équipe de développement n’en était toujours pas satisfaite. En regardant le backlog, j’ai remarqué qu’il ne contenait que des user stories détaillées, pas d’epics ou d’autres éléments grossiers. Mais un backlog de produit trop détaillé rend difficile de voir le bois pour les arbres : il y a tout simplement trop d’informations. Ceci, à son tour, rend difficile la hiérarchisation et la mise à jour de l’artefact.
Mais alors pourquoi devenir product Owner ? Découvrez notre formation dans mon centre formation
De plus, il est susceptible de contenir des éléments spéculatifs et finalement erronés, en particulier lorsque l’effort de développement est caractérisé par l’incertitude et le changement. Je vous recommande donc de commencer avec un backlog de produit initial volontairement sommaire et incomplet, surtout lorsque votre produit est jeune ou connaît une évolution plus importante. Laissez ensuite le backlog évoluer en fonction des commentaires reçus des utilisateurs, des clients et des parties prenantes. Cela vous permet de minimiser l’effort de stockage du backlog de produit et de baser vos décisions de produit sur des preuves empiriques, plutôt que sur des intuitions. Le carnet de produit n’est pas correctement affiné Il y a quelque temps, je travaillais avec une entreprise qui met en relation des consommateurs au Royaume-Uni avec une personne de métier comme un plombier ou un jardinier. À l’époque, l’entreprise était encore une startup et le product backlog m’avait demandé de l’aider à résoudre un problème de planification : l’équipe de développement s’engageait régulièrement trop et n’arrivait jamais à terminer tout le travail en un sprint.
Quand on m’a fait visiter le bureau, j’ai vu des cartes papier sur le mur avec de grandes épopées sommaires dessus, et j’ai demandé au product backlog si elles faisaient partie du backlog du produit. L’individu a répondu : “Non, c’est le backlog du produit.” Étant donné que le backlog ne contenait pas d’éléments suffisamment raffinés et prêts, je n’étais plus surpris que l’équipe de développement ait eu du mal à planifier correctement le sprint. Bien que vous ne vouliez pas rendre votre backlog de produit plus détaillé que nécessaire, vous devez vous assurer que ses éléments hautement prioritaires sont prêts . Cela les oblige à remplir les trois critères suivants : Premièrement, ils sont suffisamment clairs et compris par l’équipe de développement. Deuxièmement, ils peuvent être complétés en un sprint selon la définition du terminé. Troisièmement, ils peuvent être testés. Il est préférable de préparer les éléments hautement prioritaires avec (certains des) membres de l’équipe de développement, comme je l’explique ci-dessous.
Le Product Backlog est une Wish List Certains backlogs de produits, comme celui de 40 000 articles mentionné ci-dessus, ressemblent à une liste de souhaits, un catalogue qui contient tout ce dont vous pourriez avoir besoin. Le problème avec un tel arriéré n’est pas seulement qu’il est généralement trop important. Il en résulte également une «soupe de fonctionnalités», un produit qui ressemble à une collection lâche de fonctionnalités sans rapport. Cela conduit à une proposition de valeur faible et à une expérience utilisateur médiocre, qui ne sont guère les caractéristiques d’un excellent produit. Mais si ces arriérés sont si importants, pourquoi existent-ils ? Il y a deux raisons principales : premièrement, un manque d’alignement stratégique et d’orientation, et deuxièmement, un manque d’autonomisation.
Le premier signifie qu’il n’y a pas d’ objectif de produit qui guide la décision d’ajouter ou non un élément au backlog de produit. Vous pourriez, par exemple, faire un remue-méninges sur les histoires d’utilisateurs et décider de toutes les ajouter. Qui sait, ils pourraient être utiles à un moment donné ! Un manque de responsabilisation vous amène, en tant que Product Owner, à avoir du mal à refuser les demandes des parties prenantes et à vous sentir obligé d’y répondre. Mais si vous n’êtes pas en mesure de dire non , votre carnet de produit risque de servir les parties prenantes individuelles et leurs objectifs personnels, plutôt que de maximiser la valeur que le produit crée pour les utilisateurs et l’entreprise.
Pour éviter que votre backlog de produit ne devienne une liste de souhaits, suivez ces deux conseils : Tout d’abord, sélectionnez un objectif de produit et alignez votre produit sur un plan stratégique comme une feuille de route de produit (comme je l’explique ci-dessous). Deuxièmement, ayez le courage de dire non. Refuser toutes les idées et demandes qui ne sont pas alignées avec l’objectif du produit. (Voir mon article Boost Your Product Leadership Power pour des conseils sur l’augmentation de votre autorité.) Le carnet de produit n’est pas efficacement hiérarchisé Il y a quelque temps, je travaillais avec le chef de produit d’un nouveau produit de santé lorsque je lui ai proposé de hiérarchiser ses fonctionnalités. L’individu m’a regardé surpris et a répondu : « Je ne peux pas. Ils sont tous hautement prioritaires.
La priorisation, bien sûr, nécessite de décider de l’importance d’un élément. Si tout est hautement prioritaire, tout est également important. Cela signifie en effet que rien n’est prioritaire. Mais sans priorités claires, l’équipe de développement manque de direction. Si vous avez du mal à hiérarchiser votre backlog de produit, essayez les deux mesures suivantes : Tout d’abord, assurez-vous que les éléments du backlog de produit servent un objectif de produit spécifique , comme mentionné précédemment. Deuxièmement, sélectionnez un petit ensemble de facteurs de priorisation pratiques . Les trois facteurs que j’aime recommander sont les risques, les coûts-avantages et les dépendances. Voici comment vous pouvez les appliquer : hiérarchisez d’abord le backlog produit par risque et tenez compte des risques liés aux utilisateurs, à la technologie et à l’entreprise.
Évaluez tous les éléments du backlog avec l’équipe de développement et déplacez vers le haut ceux qui présentent le risque le plus élevé. Cette approche accélère l’apprentissage , et elle évite d’échouer tardivement lorsque changer de cap est plus coûteux. Une fois que vous avez traité les principaux risques, classez le backlog de produit par coût-bénéfice et déplacez les éléments vers le haut qui vous en donnent le plus pour votre argent , comme le dit le proverbe. Enfin, n’oubliez pas de tenir compte des dépendances tout en utilisant les deux autres facteurs. Celles-ci incluent les dépendances vis-à-vis des membres individuels de l’équipe et d’autres équipes, car elles peuvent influencer la hiérarchisation du backlog. Le carnet de produit n’est pas partagé Il y a quelques années, je travaillais avec un groupe de product backlog basés aux Pays-Bas qui souhaitaient que leurs équipes de développement s’améliorent pour fournir ce qu’ils demandaient. Il s’est avéré que les product backlog ont affiné les backlogs de produits et ont écrit eux-mêmes des histoires d’utilisateurs , puis ont transmis les éléments hautement prioritaires aux équipes de développement basées en Roumanie.
Les équipes ont fait de leur mieux pour interpréter correctement les user stories. Mais le plus souvent, ils se sont trompés, car ils avaient peu de connaissances sur les utilisateurs finaux et leurs besoins. Bien qu’un manque de collaboration dans la situation décrite puisse être évident pour un étranger, je trouve qu’il n’est pas rare que les équipes de développement ne soient pas correctement impliquées dans le travail de backlog de produit. Mais affiner, hiérarchiser et mettre à jour le backlog doit être un travail d’ équipe , comme le montre l’image ci-dessous. En tant que product backlog, invitez les membres de l’équipe de développement à travailler avec vous sur le backlog et attendez-vous à ce qu’ils vous soutiennent. Si ce n’est pas le cas, discutez du problème dans la prochaine rétrospective de sprint . Atelier collaboratif sur le backlog produit Le travail collaboratif sur le backlog produit et la co-création de ses éléments offrent les deux avantages suivants :
Premièrement, cela tire parti des connaissances et de la créativité collectives de l’équipe de développement, ce qui conduit généralement à de meilleurs éléments du backlog, des éléments aussi détaillés que nécessaire. être. En même temps, cela vous permet, en tant que responsable du produit, de transférer des connaissances sur les utilisateurs et leurs besoins à l’équipe de développement. Deuxièmement, les membres de l’équipe se sentent valorisés et respectés. Cela responsabilise les individus et augmente leur motivation à travailler sur le produit. Les gens n’ont plus d’exigences à respecter. Ils contribuent désormais aux décisions relatives aux produits et aident à façonner la solution. Si vous ne travaillez pas régulièrement sur le backlog produit avec au moins certains membres de l’équipe de développement, essayez-le.
Mettez en place un atelier collaboratif, que ce soit sur site ou en ligne, et demandez à votre Scrum Master de l’animer. Au départ, cela peut vous obliger à passer plus de temps à travailler sur le backlog du produit. Mais à plus long terme, cela devrait réduire votre charge de travail. Cela pourrait même amener l’équipe de développement à être heureuse de faire elle-même une partie du travail de raffinement. Le carnet de produit manque d’alignement stratégique
Une erreur courante de backlog de produit et une cause profonde de plusieurs erreurs discutées ci-dessus est un manque d’alignement stratégique : le backlog n’est pas systématiquement connecté à un plan stratégique comme une feuille de route de produit . Mais sans orientation stratégique et sans un objectif de produit clair qui le régit, le carnet de commandes peut facilement grossir, devenir difficile à hiérarchiser et se transformer en une liste de souhaits. C’était également le cas pour l’énorme backlog de produits que j’ai mentionné plus tôt : l’objectif stratégique du produit n’était pas clair, et il était donc difficile de déterminer quels éléments devaient être ajoutés au backlog. Je vous recommande donc fortement de connecter votre backlog de produit à une feuille de route de produit exploitable qui indique la valeur que le produit devrait créer sous forme d’ objectifs de produit pour les neuf à douze prochains mois, comme l’illustre l’image ci-dessous. Des exemples d’objectifs de produit peuvent être l’acquisition d’utilisateurs, l’augmentation de la conversation, la suppression de la dette technique pour pérenniser le produit et la réduction des coûts.
Dans la formation product owner cpf vous apprendrez à créer et optimiser au mieux votre product backlog.
Feuille de route du produit, backlog du produit et objectif du produit Dans l’image ci-dessus, une feuille de route de produit axée sur les objectifs et les résultats dirige le backlog de produit. Cela se fait en copiant le prochain objectif de produit de la feuille de route dans le backlog. L’objectif permet ensuite de déterminer les éléments qui doivent être inclus dans le backlog du produit, c’est-à-dire uniquement ceux qui permettent de l’atteindre. (Vous pouvez en savoir plus sur la façon dont la feuille de route du produit et le backlog peuvent se compléter dans mon article La feuille de route du produit et le backlog du produit .)
