Vous aurez tous reconnu la référence, mais rassurez-vous, on parle bien de backlog ici. Plus précisément, j’aimerais que vous ayez en tête l’information suivante : dans le framework Scrum, le miroir du produit se compose de deux éléments.
En effet, il comprend :
– l’incrément du produit qui sera livré par l’équipe de développement à la fin de chaque sprint,
– le backlog, produit alimenté régulièrement par le Product Owner tout au long de la vie du produit.
Aujourd’hui on va s’intéresser au Backlog !
Qu’est-ce qu’un backlog en scrum ?
Pour définir le backlog, j’aime bien le terme traduit, « carnet du produit », car c’est exactement ça ! Un carnet qui contient une liste d’items, représentant une fonctionnalité présente (ou non) dans le produit. L’item dans le framework Scrum est ce qu’on appelle une user story. En effet, on raconte l’histoire d’un utilisateur. Cela donnera une fonction à ce produit pour atteindre l’objectif de la user story.
Donc, le backlog est un ensemble de user stories, exprimées par le Product Owner, pour expliquer les fonctionnalités du produit. Il est évident que l’utilisation d’un produit est variée selon nos tendances et habitudes à avoir besoin de certaines fonctionnalités. Pareil, on en aimera certaines plus que d’autres… Peut-être parce qu’elles apportent une valeur ajoutée et différencient le produit de la concurrence. Ça peut aussi être des fonctionnalités essentielles à l’existence du produit.
Comment prioriser les tâches ?
Les deux critères essentiels pour prioriser les fonctionnalités sont :
– la valeur ajoutée qu’une fonctionnalité du produit apporte à l’utilisateur,
– le critère indispensable d’une fonctionnalité (par exemple, une pompe à eau doit apporter de l’eau en la pompant).
Cette priorisation est essentielle pour l’équipe de développement. Elle pourra se focaliser sur un périmètre pendant un laps de temps (un ou plusieurs sprints). Bien sûr, l’équipe ne peut pas travailler que sur des user stories de haute priorité. D’autres paramètres seront pris en compte comme les dépendances entres les user stories, la capacité de l’équipe de développement à produire de la valeur métier aux utilisateurs.
Ces paramètres se rajoutent au backlog durant les sprints et sont définis dans les cérémonies Scrum comme le Backlog Grooming… oups Backlog Refinement, Sprint Planning et Sprint Review. Chaque cérémonie fixe un objectif commun à chaque itération, détaille le travail à faire en rapport avec chaque user story. On y définit aussi l’effort à produire pour atteindre cet objectif.
Le sprint Review, par exemple, apportera des modifications et ajoutera des éléments au backlog. Ainsi, on pourra changer les priorités déjà exprimées et détaillées pour d’autres éléments.
Pourquoi un backlog, s’il bouge à chaque sprint et à chaque cérémonie ?
On a besoin de sa puissance de visualisation. En effet, le backlog est comme un journal personnel.
Ainsi, il permet de visualiser la vie d’un produit, en répertoriant les différents changements effectués et appréhender les futures modifications. En fait, j’ai menti quand je parlais de miroir…
Le produit n’a pas un seul miroir avec deux éléments. Il en a deux. Le premier pour l’instant présent : c’est l’incrément. L’autre est le backlog. C’est un miroir pour voir l’avenir du produit, exprimer une vision et décrire une image. Magique, non?
Backlog is the new Product requirement document ?
On accuse souvent les frameworks agiles de changer juste les termes ou la forme, mais de garder le fond. C’est faux !
Ainsi, on peut être tenté de faire le rapprochement entre backlog et cahier des charges. Même si les deux portent les fonctionnalités demandées pour construire un produit, il y a beaucoup de différences entre ces deux notions. En voici 3 :
– Le processus de construction : on construit un cahier des charges en « one shot », puis on le fige. Un backlog est plutôt dynamique et évolue au fur et à mesure de la construction du produit lui-même.
– Le niveau de détail : toutes les fonctionnalités sont détaillées dans un cahier des charges. Dans le backlog, on a un mélange selon le niveau de maturité de la réflexion sur la fonctionnalité.
– La priorité : Une expression de besoins priorise les fonctionnalités et fige ses priorités. Dans un backlog, encore une fois, tout est dynamique. On peut donc changer l’ordre des tâches, à la fin de chaque sprint suite aux feedbacks des utilisateurs.
Enfin, ce qu’il faut retenir, c’est que le backlog est la responsabilité du product owner. Néanmoins, sa construction est faite avec l’équipe de développement et d’utilisateurs. C’est une liste d’items appelée user stories qui bouge selon les priorités et s’adapte aux besoins des utilisateurs.
Tout simplement « Agile Fan » !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Nidhal
