Scrum : Qui crée les éléments de la liste de produits ou les histoires d’utilisateur ?

Cette question est plus complexe qu’elle ne le paraît au premier abord. Tout d’abord, on peut dire que Liste de produits les éléments peuvent inclure des cas d’utilisation, des épics, des histoires d’utilisateur, voire des bogues ou des tâches de recherche limitées dans le temps au sein de la liste de produits.

Dans la définition la plus simple, la Scrum liste de produits Scrum est simplement une liste de tous les éléments de la liste de produits (PBIs) qui doivent être terminés dans le projet. Elle remplace les artefacts traditionnels de spécification des exigences artefacts. Les PBIs reflètent les besoins des clients ou des parties prenantes. Une approche courante pour capturer les exigences des utilisateurs finaux consiste à écrire les PBIs sous la forme de histoires d’utilisateur.

Qui est responsable de maintenir la liste de produits ?

Le Product Owner (PO) « possède » la liste de produits au nom des parties prenantes et est principalement responsable de sa création. Le PO n’a pas besoin de créer la liste personnellement—il ou elle peut déléguer à l’équipe de développement et/ou à Scrum Master pour aider à définir et à estimer les éléments de la liste. Le PO est responsable de la création et du maintien de la liste de produits. Par conséquent, le PO supervise également le processus de affinage de la liste de produits processus.

La liste de produits correspond à votre plan de projet — le plan que l’équipe entend livrer. Une fois que l’équipe l’a définie, elle priorise les fonctionnalités et exigences à développer. La liste de produits sert également de répertoire contenant toutes les informations dont l’équipe a besoin pour suivre et partager.

Un élément de la liste de produits est-il identique à une histoire d’utilisateur ?

Comme mentionné, les PBIs reflètent les besoins des clients ou des parties prenantes. Une méthode courante pour capturer les exigences des utilisateurs finaux consiste à écrire les PBIs sous la forme de histoires d’utilisateur. Toutefois, les PBIs peuvent également inclure des cas d’utilisation, des épics, histoires d’utilisateur, des bogues ou des tâches de recherche limitées dans le temps au sein de la liste de produits. En réalité, tous les éléments de la liste de produits ne sont pas au même niveau de détail, comme indiqué sur l’image ci-dessous :

Liste de produits détaillée

Les PBIs que nous prévoyons de traiter prochainement doivent se trouver près du haut de la liste, plus petits en taille et très détaillés afin qu’ils puissent être traités en peu de temps Sprint. Les PBIs que nous n’allons pas traiter pendant un certain temps devraient se trouver vers le bas du backlog — plus grands, moins détaillés. C’est acceptable ; nous ne prévoyons pas de travailler sur ces éléments avant longtemps.

À mesure que nous nous rapprochons du travail sur des PBIs plus importants, comme les épics, nous les décomposons en une série d’histoires plus petites, prêtes pour le sprint. Cela doit être fait en temps opportun. Si nous affinons trop tôt, nous risquons de perdre du temps à déterminer des détails qui ne seront jamais mis en œuvre. Si nous attendons trop longtemps, nous bloquerons les PBIs qui doivent entrer dans le sprint et ralentirons l’équipe. Nous devons trouver le bon équilibre au bon moment.

Backlog produit priorisé Agile

Qui est responsable de l’affinage des PBIs ?

Le Product Owner (PO), qui « détient » le backlog produit au nom des parties prenantes, est principalement responsable de sa création et de son entretien. Le PO n’a pas besoin de créer chaque élément du backlog personnellement — il ou elle peut impliquer l’équipe de développement et/ou le Scrum Master pour aider à définir et estimer les éléments. Le PO supervise l’ensemble du processus d’affinage du backlog.

Par conséquent, pour répondre à la question : le Product Owner détient le backlog produit, mais n’a pas besoin de créer chaque élément du backlog. En général, le Product Owner peut créer des PBIs importants sur la base de besoins de haut niveau ou d’objectifs utilisateurs, puis déléguer à l’équipe pour aider à décomposer ces grands éléments en histoires utilisateur. Ces petites histoires — adaptées au sommet du backlog et répondant aux critères de « Prêt » (généralement sous le Définition de Prêt) — sont ensuite déplacées dans le Backlog de sprint.