Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Élaboration et priorisation du product backlog

Les raisons d’investir dans le product backlog

Le product backlog est l’épine dorsale de tout projet Scrum. Il s’agit d’une liste priorisée de tout ce qui doit être fait dans le projet, définie par le Product Owner. Les éléments du product backlog, ou "user stories", représentent des fonctionnalités, des exigences, des améliorations et des corrections qui doivent être effectuées pour délivrer un produit final de qualité. Investir du temps et des efforts pour bien élaborer et prioriser le product backlog peut avoir plusieurs avantages. Voici quelques raisons d’investir dans le product backlog.

IMAGES/05DP01.png

Clarté des objectifs du projet : un product backlog bien défini donne une vue d’ensemble claire des objectifs du projet. Chaque élément du backlog a un but précis et contribue à l’objectif global du projet. Cela aide l’équipe à comprendre ce qu’elle doit accomplir et pourquoi.

Priorisation efficace : le product backlog doit être constamment priorisé. Cela signifie que les éléments les plus importants et les plus précieux pour le produit final sont toujours traités en premier. Cela assure que l’équipe travaille toujours sur ce qui apporte le plus de valeur à l’entreprise et aux utilisateurs....

L’élément fondamental du product backlog : la user story

La user story est l’élément fondamental du product backlog. Il s’agit d’une description simple et compréhensible d’une fonctionnalité vue par l’utilisateur du produit. La user story aide à comprendre le besoin de l’utilisateur et à concevoir une solution qui y répond. Voici une description plus détaillée de ce qu’est une user story et de son importance.

Qu’est-ce qu’une user story ?

Une user story est une brève description du besoin d’un utilisateur. Elle est souvent formulée de la manière suivante : "En tant que [type d’utilisateur], je veux [faire quelque chose] afin de [bénéficier de quelque chose]". Par exemple, dans le contexte de l’application de fitness de notre équipe, une user story pourrait être : "En tant qu’utilisateur abonné, je veux pouvoir suivre mes progrès quotidiens afin de voir si je m’améliore".

images/05DP00.png

Cette formulation aide l’équipe à se concentrer sur l’utilisateur et sur la valeur que la fonctionnalité apporte. Elle aide également à maintenir la fonctionnalité à une taille gérable. Si la user story devient trop complexe, elle peut être décomposée...

La rédaction des user stories et epics

La rédaction des user stories et des epics est une étape cruciale de la gestion du product backlog. Il s’agit de transformer les besoins des utilisateurs et les grandes idées en tâches concrètes que l’équipe de développement peut réaliser. Voici comment procéder.

Un epic est une grande unité de travail qui est trop volumineuse pour être réalisée en un seul sprint. Il s’agit généralement d’une large fonctionnalité ou d’un objectif majeur qui doit être décomposé en plusieurs petites tâches plus gérables, connues sous le nom de "user stories".

1. La rédaction des user stories

Une user story est généralement écrite en suivant la structure "En tant que [rôle], je veux [action] pour que [bénéfice]". Cette structure permet de garder le focus sur l’utilisateur et la valeur que la fonctionnalité lui apporte.

Par exemple, dans le contexte de notre application de fitness, une user story pourrait être : "En tant qu’utilisateur, je veux pouvoir enregistrer mes séances d’entraînement pour pouvoir suivre mes progrès".

Lors de la rédaction des user stories, il est important de rester concis et de se concentrer sur l’essentiel. Les détails techniques et les solutions spécifiques ne doivent pas être inclus dans la user story. Ces détails seront discutés plus tard avec l’équipe de développement lors de la planification du sprint.

2. La rédaction des epics

Un epic est une grande user story qui est trop vaste pour être réalisée en un seul Sprint. Les epics sont souvent décomposés en plusieurs user stories plus petites.

Par exemple, dans notre application de fitness, un epic pourrait être : "En tant qu’utilisateur, je veux pouvoir suivre et analyser toutes mes activités physiques pour améliorer ma condition physique". Cet epic pourrait être décomposé en plusieurs user stories, comme "En tant qu’utilisateur, je veux pouvoir enregistrer mes séances de course à pied" ou "En tant qu’utilisateur, je veux voir des graphiques...