En tant que Product Owner ou Product Manager, vous êtes certainement amené à gérer un Backlog Produit.
Ce Backlog Produit, c'est d'abord et avant tout, une liste de demandes issues des métiers et/ou des services techniques, que vous complétez au fur et à mesure.
Ensuite, lors du Sprint Planning, les demandes prêtes peuvent être planifiées avec les ingénieurs et être transférées dans le Backlog Sprint.
Nous avons parfois tendance à faire de notre Backlog Produit un "fourre-tout" et à négliger les perturbations que son manque de clarté peut avoir dans les équipes Produit.
En effet, une organisation non-saine favorise souvent trois fléaux qui peuvent détruire la productivité de votre équipe et son turnover :
- Le manque de confiance : les équipes doutent de tout, même d'elles-mêmes.
- Le manque d'efficacité : l'équipe prend trop de temps pour chercher la bonne info
- La dépendance : Un membre devient indispensable pour dénouer des incertitudes
Dans cet article, vous aurez plusieurs bonnes pratiques issues de diverses expériences en grands comptes et en startups.
Il ne s'agit pas ici de recettes absolues. Il convient d'adapter ces pratiques à vos contextes et surtout de vous en inspirer pour garder le contrôle sur votre projet.
1- Créez un Backlog Sprint
Le Backlog Sprint est une liste claire de tickets candidats pour un sprint ou plusieurs sprints.
Cette liste prend en compte :
- les "histoires" (ou "stories"), les demandes de nouvelles fonctionnalités à développer;
- les "tâches", les ajustements ou optimisations à effectuer sur l'existant;
- les "anomalies" connues et parfois même, les "histoires techniques" c'est-à-dire les demandes en lien avec la dette logicielle que votre système embarque. Il peut s'agir d'un legacy, d'une refactorisation ou d'un simple cleaning.
Attention à garder à l'esprit qu'un Backlog Sprint n'a pas que son préfixe en commun avec le Backlog Produit. Par exemple, les anomalies étant incertaines, elles ne peuvent pas être chiffrées dans un Backlog Sprint. Par contre, elles doivent être clairement identifiées, testées et éprouvées comme telle dans un Backlog Sprint.
Créer un Backlog Sprint aidera votre équipe à se focaliser sur les sujets clairs, embarquables avec ou sans votre présence en tant que Product Owner ou Product Manager.
2- N'ajoutez des idées dans votre Backlog Produit que si elles sont délimitées
Votre Backlog Produit n'est pas censé devenir le fourre-tout des idées de PO / PM, de son manager ou de son équipe d'ingénieurs.
À un problème donné correspondra toujours plusieurs alternatives de réponses. Votre backlog est un premier tri sur les pistes de réponses envisagées aux problèmes que la roadmap souhaite traiter.
Ayez le courage de ne pas garder les idées fantômes, car elles diluent votre productivité, et votre confiance vis-à-vis des sujets que vous traitez.
Chaque partie prenante à votre produit devrait disposer d'un outil dans lequel il traite ses notes personnelles, afin que votre Backlog soit une liste évidente des solutions que vous souhaitez vraiment envisager à court, moyen ou long terme.
3- Commentez toutes vos décisions sur un ticket
On ne le dit jamais assez, mais que ce soit dans un Backlog Produit, un Backlog Sprint, ou un sprint en cours, chaque décision vaut la peine d'être reportée, si possible, avant que le ticket ne soit mis à jour.
Cette pratique aide votre équipe à se détacher de votre présence pour récupérer des informations capitales autour d'un sujet en particulier.
Les mots s'envolent, les écrits restent
Il est d'ailleurs recommandé d'éviter de prendre des décisions via des discussions asynchrones afin d'éviter de prendre le risque que les informations ne soient pas évaluées à leur juste valeur.
4- Créez un label pour identifier l'état d'une demande qui mérite que la qualité de la décision soit discutée
Dans la vie de votre Backlog Produit, certaines décisions sont constamment remises en question. C'est normal.
D'autres décisions peuvent remettre en question le choix de la solution adoptée et renseignée dans le Backlog Produit, afin d'embarquer un problème nouvellement identifié.
Dans ce genre de situation, prévoyez un label qui exprime le besoin d'alignement à faire sur le sujet, prévoyez un rendez-vous avec les bonnes parties prenantes et récoltez des infos avant de décider de la suite des opérations.
5 - Mettez en place un rituel pour nettoyer votre Backlog Produit
En général, lorsque vous arrivez dans une nouvelle équipe, vous avez un Backlog Produit déjà enrichi que vous devez prendre en main.
Il y a quelques semaines, j'ai demandé à mes pairs, sur LinkedIn, ce qu'ils feraient s'ils arrivaient dans une équipe Produit, avec un Backlog déjà très fourni.
70% pensent qu'il vaut mieux le supprimer et repartir de zéro tandis que le reste pense qu'il y a moyen de s'en servir pour continuer de construire.
Je suis de ceux qui pensent qu'il y a moyen de profiter d'un ancien Backlog, avant de l'envoyer à la poubelle.
Cependant, le temps que vous preniez en main ce Backlog, et que vous en deveniez pleinement "Owner", vous aurez besoin de vous faire accompagner par vos clients, votre support et vos ingénieurs, afin de le nettoyer petit à petit.
Il est fortement encouragé de mettre en place un ou plusieurs événements dont les buts sont de nettoyer votre Backlog, afin de vous aider à prendre de la hauteur sur les sujets que vous pourriez être amené à traiter, ou réaligner vos parties prenantes.
6- Ne créez pas un sous-ticket pour traiter une demande, récupérez le parent dans votre projet.
L'erreur que nous faisons souvent dans nos équipes est de créer un ticket enfant, en lien avec une demande initiale venant d'un support. Cette démarche crée mécaniquement une perte d'information lors d'une mise à jour du ticket parent, une perte de suivi par le support du niveau d'execution de la demande et enfin une perte de recul à votre niveau en tant que PO / PM.
Je recommande donc d'embarquer la demande initiale dans votre projet d'équipe et de la suivre. De cette façon, si une nouvelle information devait être diffusée en lien avec cette demande, venant du support ou de votre équipe, elle serait tout de suite centralisée et facile à ajuster.
Dans une équipe Produit, l'information et la manière dont elle circule sont capitales pour favoriser l'autonomie et la confiance sur la qualité des développements livrés.
7- Créez une documentation publique, sur les étapes de vies d'une demande, depuis l'idée, jusqu'aux étapes de déploiement.
Une instruction claire doit pouvoir être assignée, sans vous, et sans votre présence. Votre message doit pouvoir se lire tout seul. Même par votre remplacant.
Cette phrase est un mantra qui m'a accompagné pendant 5 ans. J'ai l'habitude de dire qu'un PO / PM prépare son départ sur une mission dès son arrivée. En effet, tout ce qu'il recommande ou décide doit pouvoir survivre en son absence, qu'elle soit temporaire ou définitive.
Dans ce sens, tout doit être mis en place afin de favoriser l'accès rapide à l'information et sa mise à jour de manière collaborative.
Cet exercice n'est pas toujours aisé et demande du bon sens mais aussi une prise de recul élevée en tant que PO / PM.
Dans tous les cas, la frustration autour de la gestion d'un use case est un excellent indicateur du besoin de dénouer la manière dont l'information est traitée.
N'hésitez pas à remettre en question autant que vous le pouvez vos processus, afin de les valider et les adapter à la dimension de votre équipe.
J'espère que ces bonnes pratiques vous aideront à améliorer la prise en main de vos missions.
