26/03/2014

Oubliez les Epics

Je voudrais me pencher sur ce concept d'Epic

http://referentiel.institut-agile.fr/stories.html
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

Un epic est une grosse story, qui n'est pas détaillée et n'est pas découpée en 'vraie' story, c'est à dire une story qui peut rentrer dans un sprint. L'intérêt de l'epic est donc de commencer un backlog avec des éléments assez gros pour que l'on sache jute de quoi on parle, mais sans que cela prenne trop de temps à détailler. C'est dans ce premier travail de constitution du backlog que l'équipe commence à construire son langage. Ce qui me gène par contre dans les epics, c'est quand cela devient systématique et que l'on commence à devoir rattacher une story à une epic et que cela devient de la comptabilité. Je pense que certains outils de gestion de backlog peuvent nous pousser à cette systématisation.

Ce qui fait le plus de sens pour moi aujourd'hui, c'est de n'avoir que des stories.

Lors d'un release planning, les stories en haut du backlog doivent commencer à ressembler à des story prêtes pour le sprint, qui respecte le Definition of Ready de l'équipe. Mais les story en bas du backlog ne sont constituées que d'un mot ou une courte phrase. Toutes les story sont chiffrées et le périmètre de la release est proposé. Ce périmètre peut changer mais cela permet de donner de la visibilité.

Lors d'un sprint planning, les stories doivent respecter le Définition of Ready, être INVEST et tenir dans un sprint. Cela est possible par un affinage progressif du backlog. Le product owner découpe et affine les story afin de les décrire à l'équipe. Cet affinage peut être fait par le product Owner seul, ou avec l'équipe lors d'un 'backlog refinement', ou encore pendant le planning game.

Afin de découper les stories, on peut utiliser différentes techniques. Le mieux est de trouver une sous-partie de la story qui a de la valeur. On aura recourt à un découpage technique si cette valeur métier ne peut-être obtenue sans l'ensemble de ses parties.

Pour se raccrocher à la terminologie utilisée précédemment, l'epic disparait lorsque son découpage en story est assez fin, et ce n'est pas la peine de le garder.

Le product owner peut ainsi maitriser son product backlog, son 'stock' de user story. Ce stock total doit avoir une taille de l'ordre d'une release. Le stock de story prêtes doit aussi avoir une taille de l'ordre de un sprint.

Cela fait partie de mes réflexions sur le 'faire juste à temps' au lieu de 'faire bien'.

Sources d'inspiration et références:
http://www.aubryconseil.com/post/Ma-presentation-sur-les-bacs
https://leanpub.com/agile-expression-de-besoins
http://referentiel.institut-agile.fr/invest.html
http://referentiel.institut-agile.fr/ready.html
http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Et pour terminer, une video très bien faite qui présente le 'product backlog refinement meeting'.
http://scrummethodology.com/scrum-epics/