PBI vs User Story
Récemment, un article 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, lorsque 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 tout élément qui doit être traité en premier.
Je ne suis pas sûr de cela. De plus, je ne trouve pas une 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 l'a dit votre Scrum Master, d'autres éléments peuvent également être des éléments de backlog de produit. Cependant, cela dépend de la façon dont votre SCRUM fonctionne. 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 éléments 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.
Toutes les réponses ci-dessus ne font pas référence au document source faisant autorité pour le framework Scrum: The Scrum Guide .
Carnet de produit
Il existe 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 fixe comme un plan de projet.
Le Product Backlog évolue au fur et à 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 l'enregistrement des 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é à Agile 2017 .
Lorsque nous travaillons sur des bogues, nous les ajoutons au backlog et les appelons histoires de bogues. En ajoutant des corrections de bogues dans l'arriéré de cette manière, il est clair que ce n'est pas seulement la correction de bogues. 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), c'est toujours ser stories, bug stories ou simplement stories.
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.
Il existe un malentendu commun selon lequel seules les user stories sont autorisées dans un Product Backlog. En revanche, Scrum est neutre sur les techniques d'exigence. Comme l'indique Scrum Primer ,
Les éléments du carnet de produit sont articulés de manière claire et durable. Contrairement à un malentendu populaire, 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. *
@Falcon l'a bien expliqué. Une page qui a une définition formelle est: http://en.wikipedia.org/wiki/Scrum_ (développement) #Product_backlog Ce que vous avez décrit ne doit pas être placé dans le backlog de produit selon cette description au moins.
- Les spécifications distinctes des modifications et des ajouts au produit sont appelées éléments de backlog de produit (PBI), qui forment ensemble le backlog 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, n'y perdez pas de temps". 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.