PBI vs User Story

Récemment, un élément a été ajouté au Product Backlog par le propriétaire du produit qui indique "Lorsque je vais sur la page de connexion à partir de la page x, je vois une erreur. Je veux que cette erreur soit supprimée".

Il me semble que ce n'est pas un cas d'utilisation, et ne devrait pas être un PBI (Product Backlog Item). Cependant, quand j'en ai discuté, Scrum Master m'a dit que les user stories ne sont pas des PBI et qu'un PBI peut être un rapport de bug, une tâche, une user story, n'importe quoi et littéralement n'importe quel élément à traiter en premier.

Je ne suis pas sûr de cela. Je ne trouve pas non plus de bonne définition de PBI sur le Web . Donc, ma question est, quel genre de choses peuvent entrer dans le Product Backlog en tant qu'éléments? Un élément de backlog de produit correspond-il à une user story? Sont-ils les mêmes?

Un élément de backlog de produit correspond-il à une user story? Sont-ils les mêmes?

Pas nécessairement, mais en général, ils le font. Comme votre Scrum Master l'a dit, d'autres éléments peuvent également être des éléments de backlog de produit. Cependant, cela dépend du fonctionnement de votre SCRUM. Certaines équipes ont un backlog de bogue distinct qui est également pris en compte pour les sprints, tandis que d'autres gardent ces choses dans le backlog du produit.

Deux journaux distincts rendent plus difficile pour le propriétaire du produit de hiérarchiser les tâches, car maintenant deux journaux doivent être pris en considération pour le prochain sprint. Mais ils offrent une meilleure surveillance et les deux peuvent être hiérarchisés séparément.

Donc, ma question est, quel genre de choses peuvent entrer dans le Backlog Produit en tant qu'éléments?

Cela peut être tout ce qui fait partie de la vision du produit et du parcours vers le produit que vous souhaitez créer. Il contient principalement des exigences (user stories) mais peut également contenir des actions ou des choses techniques qui n'appartiennent pas directement au produit (par exemple "Acheter un nouveau serveur pour l'équipe de développement", "Créer une publicité pour le produit"). L'arriéré devrait éviter les détails inutiles et ne devrait pas essayer de microgérer les choses techniques. Le backlog de produit peut contenir tout ce qui apporte de la valeur au produit.

Il n'y a pas le seul vrai Scrum. Parfois, des backlogs séparés sont une meilleure façon de gérer le produit, parfois ils sont juste sur le chemin. Découvrez ce qui vous convient le mieux.

Lorsque nous travaillons sur des bogues, nous les ajoutons au backlog et les appelons histoires de bogues . En ajoutant des corrections de bogues dans le backlog de cette manière, il est clair que ce n'est pas seulement la correction de bogue. Nous pouvons ajouter d'autres tâches pour nous assurer que les tests automatisés sont écrits et que la vérification est effectuée. Cela rend également plus explicite le respect du DoD.

Nous n'avons jamais utilisé le terme PBI (même si notre outil de backlog les appelle ainsi), il s'agit toujours de user stories, de bug stories ou simplement d' histoires .

C'est principalement le choix de la terminologie de votre équipe et tant que vous savez tous ce que cela n'a pas vraiment d'importance.

Toutes les réponses ci-dessus ne font pas référence au document source faisant autorité pour le cadre Scrum: le guide Scrum .

Carnet de produit

Il y a une section décrivant le Product Backlog et les éléments, souvent appelés PBI, qu'il contient.

Le Product Backlog répertorie toutes les fonctionnalités, fonctions, exigences, améliorations et correctifs qui constituent les modifications à apporter au produit dans les versions futures.

Mais n'est pas fixé comme un plan de projet.

Le Product Backlog évolue à mesure que le produit et l'environnement dans lequel il sera utilisé évoluent. Le Product Backlog est dynamique; il change constamment pour identifier ce dont le produit a besoin pour être approprié, compétitif et utile.

Histoire de l'utilisateur

Le terme user story n'apparaît jamais dans le Scrum Guide, car

c'est un cadre dans lequel vous pouvez utiliser divers processus et techniques.

L'utilisation d'une user story n'est qu'une technique possible pour enregistrer les PBI.

EN PLUS: Bien qu'il soit courant de voir le format "En tant que, je veux, donc que", il peut être contraire à son intention d'origine . Ce format gênant a également été abordé lors d' Agile 2017 .

@Falcon l'a bien expliqué. Une page qui a une définition formelle est: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog Ce que vous avez décrit ne doit pas être placé dans le backlog de produit selon cette description au moins.

Il existe un malentendu commun selon lequel seules les user stories sont autorisées dans un Backlog Produit. En revanche, Scrum est neutre sur les techniques d'exigence. Comme l'indique le Scrum Primer ,

Les éléments du carnet de produit sont articulés de manière claire et durable. Contrairement aux malentendus populaires, le Product Backlog ne contient pas de "user stories"; il contient simplement des éléments. Ces éléments peuvent être exprimés sous la forme de user stories, de cas d'utilisation ou de toute autre approche d'exigences que le groupe trouve utile. Mais quelle que soit l'approche, la plupart des articles doivent se concentrer sur la création de valeur pour les clients. *

• Les spécifications distinctes des modifications et des ajouts au produit sont appelées éléments de carnet de produit (PBI), qui forment ensemble le carnet de produit.
• Chaque PBI décrit quelque chose que les développeurs peuvent développer et fournir pour ajouter de la valeur aux parties prenantes concernées une fois terminé (voir Définition de Terminé).
• L'intervenant le plus courant est le marché ou son représentant - le Product Owner.
• Cependant, un PBI peut décrire un travail qui réduit les coûts pour l'entreprise ou réduit les efforts de l'équipe de développement, ou un outil qui aide l'équipe du chef de produit à mieux faire son travail.
• Un PBI peut décrire tout ce qui a une valeur potentielle pour une partie prenante.

Une histoire (utilisateur) est un format standard utile pour les éléments de backlog. Le raisonnement derrière cela est "si personne ne s'en soucie, ne perdez pas de temps dessus". Il permet également au bon de commande d'évaluer l'urgence de l'article car il définit pour qui vous le ferez et à quel point il est mauvais.

Dans votre cas, le bogue peut facilement être formaté comme une histoire.

• En tant qu'utilisateur
• Je veux pouvoir me connecter à partir de la page X (et ne pas obtenir d'erreur à la place)
• donc je ne vais pas perdre de temps, être ennuyé et perdre confiance dans le produit

Cela semble mériter des efforts.