Il n’est parfois pas simple de se retrouver entre tous ces éléments proposés pour constituer un product backlog. Nous allons donc voir comment mieux s’y retrouver avec tous ces éléments : feature, user-story, epic, theme… Et cela est loin d’être simple.
Pour bien comprendre tous ces concepts, nous allons les regarder un par un en se focalisant sur la notion de « user-story » que vous connaissez probablement le mieux.
Nous n’allons pas parler de la user-story dans cet article ; donc si vous avez des doutes sur sa définition, allez lire l’article suivant : definition de la user story.
Côté scrum guide, voici ce qui est dit du backlog :
Le Backlog produit liste toutes les fonctionnalités, les fonctions, les exigences, les améliorations et les corrections qui constituent des modifications à apporter au produit dans les versions futures.
Je vous l’accorde, ça n’éclaire pas vraiment surtout que « fonctionnalités » et « fonctions » peuvent paraitre proches.
Vous pouvez regarder la vidéo de La Minute Agile sur ce sujet :
Feature
La feature que nous appelons aussi fonctionnalité dans le monde francophone est une notion assez simple à comprendre. C’est un grand élément qui sera découpé en plusieurs user-stories.
Dans l’univers de l’agilité, tout le monde est à peu prêt d’accord sur la définition de ce terme feature.
Vous pouvez regarder la vidéo de la minute agile sur ce sujet de feature :
Thème
La notion de thème est plus partagée. Il existe deux visions dans l’univers de l’agilité.
La première vision du thème est que c’est un terme synonyme de feature. En effet, certains agilistes considèrent que c’est exactement la même chose. Si votre équipe estime que cette version leur convient, il lui suffira de choisir le terme qu’elle préfère.
La deuxième vision qui existe est de dire que le produit a de grands thèmes, qui sont eux même découpés en feature. Cette vision des choses posent problème à certains car ce niveau supplémentaire peut poser plus de problème dans la priorisation. C’est en effet une idée qui est entendable.
Dans ce cadre, nous aurions ce type de découpage :
L’Epic
L’Epic que nous appelons rarement épopée dans l’univers francophone est probablement la notion la plus complexe. Mike Cohn parle d’Epics pour parler d’une longue histoire qui sera peut-être découpée en user-stories (on en a même pas la certitude) pour être développée. Il est définit par un simple label.
En fait l’Epic est une première idée décrite par un simple label qui deviendra après des travaux d’affinage 1 ou plusieurs user-stories.
Le framework SAFe va lui définir l’Epic comme un niveau supérieur à la feature.
Cependant les logiciels les plus populaires comme Jira utilise la notion d’epic mais pas la notion de feature. Les équipes peuvent changer le nom par elles-mêmes pour remplacer Epic par Feature. Cependant il est impossible d’ajouter le niveau complémentaire pour avoir les deux sans l’utilisation de plugins complémentaires.
Jira d’ailleurs dans son blog, donne la bonne définition de l’Epic. Mais les équipes apparente l’utilisation des Epics à des feature.
Mais soyons honnête ce n’est pas très grave si l’équipe est alignée sur cette utilisation du terme Epic.
Vous pouvez regarder la vidéo de la minute agile sur le sujet :
lors de mes formations, je choisis l’approche « thème est synonyme de feature » et je fais l’analogie avec un réseau social:
Story: envoyer une demande d’ami
Epic: suggérer des amis à l’utilisateur
Feature: gérer mes amis
Bonjour,
Merci la définition ets plus claire maintenant, j’ai deux questions svp: en mode SAFE : quand un PO doit rediger une feature avant les deux jours du PI (parmi les actions de préparatifs du PI) ou après le lancement du PI ?
Autre chose : c’est quoi une comite de validation des feature? De qui est elle composée ? Et quel rôle occupe un PO dedans ?
Merci bcp d’avance
L’idéal est que le PO rédige les User stories à 1 sprint à l’avance. Iln’est pas conseillé de tout rédiger avant le PI.
Le PO est celui qui valide mais il peut constituer un comité pour l’aider : avec parties prenantes.