Générer et gérer le backlog de produit

Article
06/10/2015

Par Mitch Lacey. Propriétaire : Mitch Lacey & Associates, Inc, cabinet de consultants spécialisé dans l'adoption et l'amélioration des pratiques Agile et Scrum.

Janvier 2012

Dans cet article, Mitch Lacey explique l'importance d'un journal des travaux en souffrance du produit, décrit ce qui fait un bon journal des travaux en souffrance, et fournit quelques meilleures pratiques pour créer et mettre à jour votre journal des travaux en souffrance.

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server (TFS)

Dans cet article :

Introduction
Journal des travaux en souffrance du produit
- Récits utilisateur
- Estimation
- Hiérarchisation
Journal des travaux en souffrance du produit vivant
- Nettoyage

Un journal des travaux en souffrance du produit est une liste hiérarchisée de toutes les fonctionnalités nécessaires pour mener à bien un projet. Dans TFS, vous gérez votre journal des travaux en souffrance du produit à l'aide d'éléments de travail. Les types d'éléments de travail que vous choisissez dépendent du modèle de processus utilisé pour créer votre projet d'équipe. Pour plus d'informations sur les modèles de processus et les types d'éléments de travail pris en charge, consultez Utiliser des artefacts de projet d'équipe, choisir un modèle de processus.

Un journal des travaux en souffrance du produit correct est au cœur de toute équipe Agile performante et présente les caractéristiques suivantes :

Il est hiérarchisé pour que l'équipe crée d'abord les fonctionnalités les plus importantes.
Il est estimé par l'équipe pour éclairer le directeur de produit et lui permettre de répondre aux questions telles que « Quand ces récits seront-ils terminés ? ».
Il comprend tout le travail nécessaire à la réalisation du projet.
Il s'agit d'un document vivant, qui évolue constamment pour refléter les réalités actuelles du projet.

Un journal des travaux en souffrance du produit correct ne garantit pas automatiquement la bonne qualité du logiciel. Toutefois, l'absence d'un journal des travaux en souffrance du produit correct aboutit souvent à un logiciel incomplet qui ne répond pas aux besoins de vos clients et parties prenantes.

La gestion du journal des travaux en souffrance du produit est un travail à temps complet. Des techniques simples permettent de transformer un processus écrasant et gourmand en temps en un processus interactif et itératif qui intéresse efficacement les membres de l'équipe, les clients et les parties prenantes. Vous devez donc apprendre des techniques solides pour créer, hiérarchiser et tenir à jour votre journal des travaux en souffrance du produit.

Journal des travaux en souffrance du produit

Le journal des travaux en souffrance du produit est une liste principale vivante et hiérarchisée de toutes les fonctionnalités nécessaires pour mener à bien le projet. En règle générale, les journaux des travaux en souffrance du produit comprennent des récits utilisateur (par exemple, des besoins), des bogues, des tâches de recherche et des améliorations d'ingénierie. Ces éléments sont estimés dans des unités abstraites souvent appelées « points de récit ».

Les journaux des travaux en souffrance du produit comprennent tout le travail dont le projet aura besoin au fil du temps. Ainsi, ils contiennent non seulement les nouvelles fonctionnalités pour un produit, mais également les résolutions de bogue et la recherche, c'est-à-dire tout ce qui prend du temps à l'équipe. Tout le travail que l'équipe est amenée à effectuer doit provenir du journal des travaux en souffrance du produit : il représente la porte d'entrée du projet. Si le journal des travaux en souffrance du produit comprend tout le travail, le directeur de produit, l'équipe et l'encadrement ont une meilleure image du travail restant, ce qui réduit le risque de surprises de dernière minute.

Au début de tout projet, il est rare que vous disposiez d'une jolie liste d'éléments de journal des travaux en souffrance du produit nets et correctement définis pouvant être estimés et hiérarchisés. À la place, vous possédez probablement une pile de fiches de récit et éventuellement une ou deux spécifications fonctionnelles. En tant que directeur de produit, vous devez y mettre de l'ordre pour que l'équipe puisse commencer à estimer le journal des travaux en souffrance.

Récits utilisateur

La première étape consiste à convertir toutes les idées et notes en récits utilisateur, qui expriment les fonctionnalités souhaitées par l'utilisateur final (ce que le logiciel doit effectuer), mais pas les détails de l'implémentation (la façon de créer un logiciel qui répond à ces besoins). Le titre de chaque récit utilisateur doit suivre le format « en tant que <utilisateur>, je souhaite la <fonctionnalité> pour que <motif> ».

Exemple de scénarios en images

À l'image du journal des travaux en souffrance du produit proprement dit, chaque récit utilisateur évolue au fil du temps. À mesure que le projet progresse, votre équipe hiérarchise et estime ces récits, y ajoute des informations détaillées, et les décompose en récits plus petits ou les supprime tous. Ceux qui sont intégrés à des sprints sont implémentés et fournis à vos clients.

Pour plus d'informations sur les récits utilisateur, consultez Créer votre backlog et Créer un plan conceptuel de vos idées à l'aide de PowerPoint.

Après avoir converti toutes les idées et notes en récits utilisateur, vous devez effectuer l'estimation et la hiérarchisation.

Estimation

Par définition, l'estimation est imprécise. Toutefois, avec le temps, de la pratique et la participation de toute votre équipe, vous pourrez créer des estimations de plus en plus précises. La première étape consiste à réunir l'équipe chargée de fournir des estimations sur les éléments du journal des travaux en souffrance du produit. Quand l'équipe estime chaque récit, elle lui attribue une taille relative avec une unité de mesure abstraite, appelée « point de récit ».

Les estimations sont essentielles pour deux raisons :

Elles permettent de répondre à la question « Quand aurons-nous terminé ? »
Elles aident le directeur de produit à déterminer la priorité de chaque élément.

Les estimations donnent au directeur de produit et à l'équipe une idée du coût d'un récit particulier, les différents coûts permettant alors au directeur de produit de hiérarchiser les récits. Plus l'estimation de l'élément est conséquente, plus son implémentation demandera du temps et des ressources. Ainsi, un élément qui occupe une position élevée dans la liste de souhaits d'un directeur de produit peut voir sa priorité baisser si son coût est élevé.

L'équipe peut utiliser des techniques telles que le Planning Poker ou le Big Wall pour estimer le travail en termes de points de récit. Pour plus d'informations sur les techniques d'estimation et une rapide leçon sur les points de récit, consultez Estimation et Nettoyer et estimer le journal des travaux en souffrance (backlog).

Une fois que l'équipe a estimé tous les récits, l'étape suivante est la hiérarchisation.

Hiérarchisation

Tous les journaux des travaux en souffrance du produit sont hiérarchisés en termes de valeur commerciale et de risque. Le directeur de produit compare chaque élément du journal des travaux en souffrance aux autres pour déterminer sa priorité relative. Pour ce faire, il prend en compte la taille de chaque élément, sa valeur pour l'entreprise et tout risque associé. Les éléments sont ensuite triés par ordre de priorité décroissant. Les éléments à priorité élevée se trouvent en haut, ou dans la partie haute, du journal des travaux en souffrance du produit, tandis que les éléments à priorité moins élevée résident en bas, ou dans la partie basse. Les équipes choisissent le travail pour le sprint à venir parmi les éléments les plus prioritaires, afin que les éléments les plus importants soient traités en premier.

Tous les éléments du journal des travaux en souffrance n'ont pas la même taille. Certains peuvent être traités dans un sprint, tandis que d'autres sont tellement volumineux que l'équipe n'a pas une idée précise des tâches qu'ils impliquent ou de la durée nécessaire à leur implémentation. Ce n'est pas un problème. À mesure que les éléments se rapprochent du haut du journal des travaux en souffrance, l'équipe réduit leur taille et leur portée pour que chaque personne comprenne mieux le travail qui l'attend au cours des sprints à venir.

Comme l'estimation, la hiérarchisation du journal des travaux en souffrance du produit initial peut être décourageante. Comment trouver le meilleur équilibre entre toutes les demandes des parties prenantes, tout en prenant en considération le produit final, les risques et les coûts ? Heureusement, plusieurs techniques facilitent cette tâche, notamment Innovation Games et Relative Weighting. Pour plus d'informations sur ces techniques et sur d'autres, consultez Définition de priorités et Nettoyer et estimer le journal des travaux en souffrance (backlog).

Quelle que soit la technique de hiérarchisation que vous choisissez, vous devez organiser le travail de manière à ce que l'équipe crée des fonctionnalités qui valorisent au mieux l'entreprise, les parties prenantes et les clients. Si vous ne hiérarchisez pas le travail, vous risquez de fournir des récits utilisateur à faible priorité au lieu de récits utilisateur à priorité élevée et des récits utilisateur incomplets quand les ressources et les planifications changent.

(Pour plus d'informations sur la nature des éléments du journal des travaux en souffrance, consultez Créer votre backlog et Utiliser des journaux des travaux en souffrance du portefeuille).

Journal des travaux en souffrance du produit vivant

Jusqu'à maintenant, j'ai concentré mon propos sur le processus menant à un journal des travaux en souffrance du produit estimé et hiérarchisé. À la différence d'un document d'exigences, les journaux des travaux en souffrance du produit ne sont pas créés au début du projet, puis laissés sur une étagère. En effet, le journal des travaux en souffrance du produit évolue, s'étendant ou se contractant en fonction des réalités du projet. Certains éléments du journal des travaux en souffrance du produit deviennent sans intérêt et doivent être supprimés. D'autres surgissent et doivent être décomposés en récits plus petits. De nouveaux récits utilisateur sont ajoutés, estimés et hiérarchisés à mesure qu'émergent des contraintes supplémentaires.

L'équipe et les parties prenantes sont impliquées dans la création et la gestion du journal des travaux en souffrance du produit, mais le directeur de produit en a la responsabilité ultime. Le directeur de produit doit s'assurer que le journal des travaux en souffrance est net, hiérarchisé et à jour afin que les clients et l'équipe aient une image claire du plan de travail pour la publication du projet. Même une fois que le projet a atteint sa vitesse de croisière, les directeurs de produit ont beaucoup de travail à effectuer pour que le journal des travaux en souffrance du produit demeure en bon état :

Ajouter et hiérarchiser de nouveaux récits
Demander à l'équipe d'estimer les nouveaux récits et d'estimer une nouvelle fois les anciens au fur et à mesure qu'ils sont mieux assimilés
Examiner les récits utilisateur à venir avec l'équipe pour décomposer les éléments selon les besoins
Se réunir avec les clients et les parties prenantes pour examiner les exigences et en ajouter

Toute personne peut ajouter des éléments au journal des travaux en souffrance du produit à tout moment, mais seul le directeur de produit peut les hiérarchiser. Le directeur de produit est également la seule personne qui peut affecter une priorité à un récit. Tous les autres membres de l'équipe, et les parties prenantes, doivent laisser la priorité vierge quand ils ajoutent un récit, même s'ils utilisent un outil électronique qui les invite à indiquer cette information.

Quand un récit est ajouté, le directeur de produit effectue une évaluation préliminaire de sa priorité en fonction de sa compréhension du récit. Il abordera le récit avec son créateur pour mieux le comprendre afin de pouvoir, ensuite, répondre aux questions émanant de l'équipe. À un moment prédéterminé de chaque sprint, le directeur de produit se réunit avec l'équipe pour discuter des nouveaux récits et les estimer collectivement afin de pouvoir les hiérarchiser plus précisément par rapport aux autres récits dans le journal des travaux en souffrance. Ce processus est appelé « nettoyage du journal des travaux en souffrance ».

Nettoyage

Le nettoyage du journal des travaux en souffrance du produit, comme indiqué précédemment, doit se produire régulièrement.

Dans Scrum, l'équipe doit consacrer 5 à 15 % de son temps pour chaque sprint à des activités de nettoyage. L'équipe doit comprendre ce qui se présente à elle et ce qui évolue, afin de pouvoir décomposer tout récit volumineux dont la priorité augmente, estimer les récits qui ont été créés et effectuer quelques tâches de conception et de planification pour les récits à venir. À cette fin, le directeur de produit et l'équipe doivent, pendant chaque réunion de planification d'un sprint, définir une plage, dans ce sprint, qu'ils consacreront au nettoyage du journal des travaux en souffrance. Pour plus d'informations sur la planification des sprints, consultez Planification de sprint et Travailler dans des sprints.

Pendant un sprint de deux semaines, j'aime tenir cette réunion au cours de la deuxième semaine. Ainsi, le directeur de produit dispose de suffisamment de temps pour avoir des conversations fructueuses avec les clients et les parties prenantes, comprendre les changements dans l'entreprise et clarifier les récits utilisateur, ainsi que les récits nouveaux ou ceux dont la priorité augmente. C'est également un moment pendant le sprint qui se prête à l'anticipation des sprints à venir. Vous pouvez décider du moment auquel tenir la réunion. Il est toutefois important de prévoir suffisamment de temps pendant le sprint pour les activités de nettoyage.

Au cours d'une réunion de nettoyage classique, le directeur de produit présente les nouveautés, les changements et son plan pour les tout prochains sprints. En plus d'estimer les nouveaux récits et de décomposer ceux qui doivent être terminés prochainement, l'équipe consacre du temps pendant cette réunion à l'examen de l'architecture actuelle du système, ainsi qu'à la planification et à la conception de futures fonctionnalités. Au cours de ce processus, les estimations de récit changent souvent, et de nouveaux récits ont tendance à apparaître quand des récits volumineux sont décomposés en récits plus petits.

D'apparence simple, ce processus peut être un peu difficile. Pour que les choses avancent en douceur, le directeur de produit doit être préparé à répondre aux questions. Un conflit peut surgir si, par exemple, le directeur de produit planifie un récit à terminer au cours du prochain sprint alors qu'il ne peut pas fournir à l'équipe toute la clarté nécessaire pour qu'elle propose une bonne estimation. Si cela se produit pendant vos réunions de planification de sprint, le ScrumMaster doit indiquer au directeur de produit les informations qu'il doit obtenir auprès des clients et parties prenantes et fournir à l'équipe.

À la fin de chaque réunion de nettoyage, le directeur de produit doit publier les modifications à l'intention des parties prenantes et des clients afin que chacun puisse prendre connaissance des nouveautés, des prochaines évolutions et du plan de publication mis à jour.

Un journal des travaux en souffrance du produit correct garantit que le logiciel que vous créez possède les fonctionnalités les plus importantes, telles qu'identifiées au cours de vos conversations avec les clients et les parties prenantes et que définies dans vos récits utilisateur. Pour créer et tenir à jour un journal des travaux en souffrance du produit correct, vous devez coopérer activement et régulièrement avec le groupe de parties prenantes/clients et avec l'équipe à l'occasion de chaque sprint.

La création d'un journal des travaux en souffrance correct ne garantit pas un système adéquat, mais l'absence d'un journal des travaux en souffrance correct aboutit presque inévitablement à un système dont les fonctionnalités ne répondent pas aux demandes des clients. En d'autres termes, ne pas tenir le journal des travaux en souffrance à jour entraîne pratiquement toujours l'échec du projet.

Le directeur de produit remplit une fonction à temps complet et assume la responsabilité du journal des travaux en souffrance. Ce rôle doit être pris au sérieux. Maintenez le journal des travaux en souffrance du produit en bon état : vos clients vous en sauront gré.