N’avez-vous jamais été troublé par l’utilisation faite des termes comme « épiques » ou « fonctionnalités » ? Certaines équipes les utilisent sans en garder nécessairement la même signification, d’autres inventent même leurs propres termes. Cela peut être assez confus pour un nouveau-venu et peut même engendrer des erreurs.
Le Guide Scrum a été écrit de façon assez ouverte pour ne pas contraindre les équipes à utiliser une règle, mais à s’adapter. C’est bien sûr une bonne chose, mais cela crée aussi des complications quand des équipes ou des blogs/sites, utilisent un même mot comme “épiques” pour décrire des éléments différents. Scrum ne décrit pas d’histoires, d’épiques, etc. Scrum décrit des Product Backlog Items (ou PBIs, ou “Item du Backlog Produit”), qui sont généralement découpés en épiques, histoires, tâches techniques ou bugs dans la plupart des équipes, parce que c’est utile.
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. Les items du Backlog produit ont les attributs d’une description, d’un ordre, d’une estimation et d’une valeur. Les items du Backlog produit incluent souvent des descriptions de test qui prouveront leur complétude lorsqu’ils sont « Finis ». Le Guide Scrum™
Tout est PBI !
L’idée d’utiliser des user stories (ou histoires d’utilisateur) vient d'Alistair Cockburn (un des signataires du Manifest Agile) en 1998, comme il l’explique sur son site. Puis en 2001, Ron Jeffries à proposé la formule des “Trois Cs” pour la création des histoires, utilisant le format adopté dans la plupart des équipes Scrum aujourd’hui.
En tant que …, je souhaite que … dans le but de …
Telle que décrite dans le livre que je recommande à tous de lire, Essential Scrum par Kenneth S. Rubin, une épique est une histoire, qui est trop grande pour être réalisée dans un sprint.
une grand histoire, potentiellement de plusieurs semaines à plusieurs mois en taille […]. Les épiques sont utiles comme espaces réservés pour de grands pré-requis. Les épiques sont progressivement redéfinies en de petites histoires, au moment opportun. Une épique sera donc découpée en de petites histoires et ne restera pas. Si vous avez 4 histoires représentant ce qu’était votre épique, l’épique disparaît, remplacée par 4 histoires.
Les épiques deviennent des histoires
Jeff Patton n’aime pas trop devoir retirer l’épique une fois celle-ci découpée, comme il l’explique sur son blog. Je peux comprendre, néanmoins je pense important de la supprimer, pour la clarté. La solution peut alors être de garder un lien entre toutes les histoires d’une épique, comme une annotation sur la carte –ou sur la tâche dans le cas d’un logiciel de gestion de produit.
Cette grosse histoire donnait un contexte. C’était ma façon simple de penser globalement à ce que les gens faisaient. C’était ma façon rapide d’expliquer à d’autres le sujet. Pour moi, un “thème” –parfois appelé “fonctionnalité”– est justement fait pour ça. Le livre de Kenneth S. Rubin définit un thème comme : … une collection d’histoires. Un thème apporte une façon commode d’indiquer que des histoires ont quelque chose en commun, comme à faire partie de la même fonctionnalité.
Histoires par thème
L’outil que vous avez choisi pour gérer votre backlog peut aussi vous avoir conditionné votre vision de l’épique. Des logiciels comme Jira ou Yodiz utilisent les épiques pour relier un groupe d’histoires entre elles. Pour moi encore une fois, ces épiques sont en fait des “thèmes”. D’autres logiciels n’ont pas d’a priori, ou, comme IceScrum, ont incorporés la notion de “Features” (fonctionnalités) pour regrouper les histoires reliées. Le logiciel permet d’ailleurs de transformer une histoire en épique et vice versa. Ce qui est - à mon avis - la meilleure façon de faire.
Bien entendu, en tant que Scrum Master, vous devez vous adapter à ce qui se fait déjà dans l’entreprise, ou prendre du temps pour changer en amont (si cela en vaut la peine). Discutez-en avec les intéressés, argumentez. Il est même possible d’avoir une définition au sein de l’équipe de ce qu’est une épique, qui diffère de celle du reste de l’entreprise, mais cela aura aussi un coût.
Le choix est arbitraire. Quelque soit votre choix, tenez-y vous. Je vous ai donné ma vision –qui est certainement biaisée par la façon dont j’ai appris Scrum (dans le livre de Rubin) et de part les meetup auxquels j’ai pu participer. Gardez en tête que votre Définition of Ready devrait établir une valeur maximale pour une histoire pour entrer dans le sprint. Si elle est trop grosse, l’appeler “grosse histoire” ou “épique” revient au même : it shall not pass si elle n’est pas** INVEST**. Publié initialement sur const.fr le 29 janvier 2018.
