Qu’est-ce qu’un élément de backlog?
Anciennement appelé PBI pour Product Backlog Item, la version 2020 de scrum parle d’élément de backlog (Backlog element). Nous parlons également de ticket, parfois de tâche, et par abus de langage, « User Story ».
Un élément de backlog est également:
- l’expression d’un besoin utilisateur
- Une description du produit
- Un élément de planification
- Un support à l’échange (3c)
- Un mécanisme pour retarder la conversation (pour qu’elle soit faite au bon moment, pas pour l’éviter)
Les différents éléments de backlog
Liste non exhaustive d’éléments que nous pouvons trouver dans un backlog
- Theme
- Épic (Epic / feature)
- Histoire utilisateur (User story)
- Demande métier (Business requirement)
- Tâche (Task)
- Activateur (Enabler)
- Sous tâche (sub task)
- Spike (et là, je n’ai pas la version française).
- Dysfonctionnement (Bug)
- …
Le détail de ces éléments fera probablement l’objet d’un article dans le futur)
Merci Ken Beck
Que dit le guide
L’affinement du Product Backlog consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s’agit d’une activité continue visant à ajouter des détails, tels qu’une description, un ordre et une taille. Les attributs varient souvent en fonction du domaine d’activité.
Scrum guide 2020
Ce que j’en déduis:
Pour une nouvelle demande, nous pourrions avoir:
- Un titre
- Une description
- Une taille
- Une valeur métier.
Pour un bug:
- Titre
- Description
- Reproduction Steps
Dans tous les cas, l’item doit être suffisamment petit pour être « done » en un sprint (éventuellement développé par plusieurs personnes).
L’item doit être suffisamment décrit et compris par l’ensemble de l’équipe. Donc, l’item en lui-même n’est pas suffisant, le contenu doit faire l’objet d’une discussion avec les membres de l’équipe.
La taille maximum de l’item est donc relative à la longueur du sprint. Gardons à l’esprit qu’avoir un élément qui prend tout le sprint n’est absolument pas une bonne pratique.
Proposition de structure
Je compte ici m’attarder sur le Bug et la demande de fonctionnalité (nouveauté ou changement)
Un titre
Une petite phrase simple qui correspond à ce qui est demandé et permet de distinguer les tickets aisément dans une liste.
Ce titre doit avoir du sens, c’est un peu comme le titre d’un livre, d’une histoire, il décrit l’activité qui sera créée.
Une description
Elle est exprimée sous forme d’histoire utilisateur / narration
« En tant que {role} je souhaite {une fonctionnalité} afin de {un bénéfice} », et/ou sous forme de texte.
C’est d’ici que tout part, c’est sur cette base que l’équipe va avoir une conversation et estimer le travail à faire.
Une estimation
L’estimation est une manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé.
Pour ce qui est du bug, il n’est estimable que lorsqu’il est bien compris, et donc que la majorité de la complexité est résolue. Un bug n’est donc pas toujours estimable.
Plus d’information sur les estimations
Des critères d’acceptation
Beaucoup plus utile pour le développement d’une fonctionnalité, mais peuvent également être repris pour un bug, après tout, ce sont certainement des choses qui étaient demandées dans le ticket d’origine et qui ne sont plus respectée.
Les critères d’acceptation sont un ensemble de critères décrits du point de vue de l’utilisateur (persona / machine), afin de déterminer si une histoire utilisateur est finie (done) et fonctionne comme prévu.
Donc, un ensemble d’exigences qu’un ticket doit satisfaire pour être considéré comme done.
Ils sont uniques pour chaque ticket.
Bien entendu, ils vont arriver au fur et à mesure que la story se crée et se précise. Ils changeront donc potentiellement jusqu’à ce que le ticket accède au statut de « ready ».
Plus d’information sur les critères d’acceptation
Tests cases
Basé sur les critères d’acceptation pour le Happy et créé de toute pièce pour le unhappy flow, ils vont aider le codeur à gérer directement tous les cas possibles et orienter au mieux l’utilisateur du système quand il sort du chemin attendu.
La présence des tests case avant le développement participe à la qualité du produit et à un développement plus rapide, car ils vont éviter des aller-retour.
Nous parlons ici d’un shift left des tests.
Résolution technique
Le résultat des conversations entre les dev pour réaliser l’item. Ceci aide à établir le plan nécessaire à tous les sprints. Ceci est également nécessaire quand le dev en charge de l’analyse technique n’est pas la personne qui développera effectivement la fonctionnalité.
Pour rappelle, l’output d’un sprint sont l’objectif de sprint, le contenu du sprint et un plan de réalisation du dit contenu.
Des liens
Et oui, il est peu probable que ce ticket ne soit pas lié à un autre de l’application, il ajoute une fonctionnalité accessible depuis telle partie de l’application, il améliore telle autre, c’est la version 1 de tel « truc » …
Il est également possible que ce ticket soit le résultat de la découpe d’un plus gros, et donc, bien entendu, le tout est lié.
C’est d’autant plus important pour un bug qui cherche à récupérer la valeur perdue (puisque ça ne fonctionne pas) d’un élément du backlog.
Et enfin, ça ajoute du contexte à ce qui doit être développé.
Des documents
Un graphique eml, un document technique, une maquette, la liste des composants déjà créés à réutiliser, une référence vers un wiki, peut importe, tout ce qui aide à la réalisation du ticket.
Pour conclure
Tous les éléments de backlog sont à contextualiser à leur fonction (histoire utilisateur, bug …), les attributs changeront donc sensiblement.
Chaque équipe doit établir son propre modèle, sa liste d’attribut par type d’élément de backlog.
Last but not least, il ne faut pas remplir un attribut parce qu’il existe, si il n’y a pas de plus value, ignorons le.
Construire mes éléments de backlog
Voici un atelier pour déterminer avec ton équipe ce qui est nécessaire dans vos éléments de backlog.
Que mettre dans un élément de backlog
One thought on “L’élément de backlog”