L’approche de réalisation en mode Agile la plus répandue

Je rencontre souvent des interprétations différentes de l’Epic. Cela varie selon la structure des organisations, ou de leur maturité en la matière.

J’ai pu noté trois principale approches pour la notion d’Epic

Epic comme super user story

Après tous, la traduction d’Epic en français c’est « épopée ». La définition de Larousse pour ce mot est

Long récit poétique d’aventures héroïques où intervient le merveilleux.

Dictionnaire Larousse

Bon, on laissera de côté héroïque et merveilleux, mais cela dit bien « Long récit »

En 2004, dans son livre « User Stories Applied to Agile Software Development »,  Mike Cohn décrit l’Epic comme suit (traduction personnelle) :

«Une User story trop large est parfois qualifiée d’epic».

Mike Cohn

Mike a précisé sa pensée dans cet article que je traduis ici :

« Nous appelons renommons les grandes User story, « Epic » pour communiquer quelque chose à leur propos. J’aime faire le parallèle avec le cinéma. Si je vous dis que ce film est un « film d’action » cela vous donne des idées sur ce que vous pourriez trouver dedans. Il y aura probablement des poursuites, probablement des tirs, etc. De même, qualifier une User story d’Epic peut parfois apporter une signification supplémentaire.

Imaginez que vous me demandez si j’ai eu le temps hier d’écrire la user story à propos du système de rapport mensuel. Je vous réponds, « Oui, mais ce sont surtout des Epic. » Cela vous indique qu’alors je les écrivais, je n’ai pas eu la chance de les détailler. »

On emploie alors ici plus « Epic » comme un adjectif que comme un sujet. De la sémantique, certainement, mais qui est immédiatement parlant pour tous.

Pour mémoire, il s’agit de la définition originale de l’Epic que l’on peut trouver dans le glossaire agile.

Epic comme un type distinct d’élément dans le backlog

À force de vouloir ajouter de la rigueur dans le backlog, certaines équipes commencent à envisager les éléments du backlog comme des spécifications. Elles veulent alors avoir une organisation hiérarchique de ces éléments et des outils qui supportent cette organisation.

L’Epic devient alors un élément à part entière du blacklog, mais est toujours lié aux user stories

Jira d’Atlassian en donne la définition suivante (traduit par mes soins) prenons par exemple cette description de l’épopée d’Atlassian:

Une épopée est un élément de haut niveau qui peut être décomposé en plusieurs user story plus petites. Par exemple, des travaux liés aux performances dans une version. Une Epic peut-être multiprojets si plusieurs projets sont inclus dans le board auquel l’Epic appartient.

Lorsque les Epic sont devenues un concept distinct des user stories, et que les deux ont été considérées comme des exigences, les utilisateurs ont cherché à les différencier des user stories. Certaines équipes ont créé des règles sur leur relation et notamment sur le fait qu’une super story puisse ou non exister sans une Epic associée.

Avoir une telle hiérarchie aide les équipes à conserver les idées à un niveau d’abstraction suffisamment haut jusqu’à ce qu’elles soient prêtes à être implémentées, et de garde une vision cohérente globale. Mais cela accroit le temps et les ressources nécessaires pour gérer cette organisation.

Epic comme un projet (mais chuuut)

Scaled Agile Framework (SAFe) se différencie des deux premières approches en poussant le concept de hiérarchie à un tout nouveau niveau.

Au lieu d’avoir d’un backlog contenant des éléments de tailles différentes, vous avez team backlog avec des user stories, un program backlog des fonctionnalités (features) et portfolio backlog avec des epics.

Dans ce cas, ce ne sont plus les super user stories que nous avons présentées au début, mais des « conteneurs d’initiatives »:

Une Epic est un conteneur pour une initiative de développement d’une solution suffisamment importante pour nécessiter une phase d’analyses, la définition d’un MVP (minimum viable produc), et une approbation financière avant implémentation.

Traduction: C’est quelque chose qui ressemble presque, mais pas tout à fait, à un projet.

Cette escalade du concept d’Epic a vraiment ajouté de la confusion, car maintenant, lorsque vous dites « Epic », vous devez comprendre s’il s’agit de la définition SAFe ou les autres (qui se rapprochent plus de la définition d’une « feature » dans SAFe).

Comment pouvons-nous clarifier un peu cette confusion ?

La chose la plus simple à faire pour que cette définition soit la même entre toutes vos équipes est de définir ce que cela veut dire POUR VOUS. Et de toujours veiller à utiliser l’Epic avec cette signification.

Une approche encore meilleure consiste à revenir à l’idée d’origine de la user story. Concentrez-vous à parler des éléments de votre backlog et moins de temps à les classer et à les documenter. Ce faisant, vous constaterez que vous n’avez peut-être même pas besoin de notion d’Epic.

Concentrez-vous sur le résultat que vous essayez d’obtenir de vos efforts plutôt que sur la façon dont vos résultats sont représentés.

Rappelez-vous deux choses :

  1.  » Le véritable objectif des user stories est de partager la compréhension « , Jeff Patton tiré de son ouvrage « User Story Mapping ».
  2. VALEUR = POURQUOI / COMMENT, donc focalisez-vous plus sur le POURQUOI que sur le COMMENT pour maximiser votre VALEUR.

L’Epic a un sens en terme métier, mais peu pour les développeurs qui doivent plus se concentrer les user stories et leurs tâches associées.

Epic ou user stories restent des stories quelque soient leurs tailles et elles n’ont de sens que si elles sont accompagnées de conversations entre le métier et l’équipe de réalisation.

La bonne taille pour une user story est la taille qui facilite la conversation. Le nom que vous lui donnez ensuite n’a pas d’importance.

Aller, A+

Article original traduit et augmenté : https://www.agilealliance.org/epic-confusion/

J’ai un jour été coordinateur de projets informatiques et une sorte de Head of Product Owner team. Je m’occupais des exigences métiers, de la mise en œuvre et de la livraison de projets web et mobiles. Bien sûr, pas tout seul.

Comme tout le monde, nous nous concentrons principalement sur les valeurs livrées à nos clients. Comme tout le monde, nous devions atteindre un niveau de qualité élevé et avec un time to market minimum . Comme tout le monde, le budget blablabla … Vous connaissez tous cette histoire.

Mais nous ne sommes pas tous d’accord sur la qualité minimale attendue. J’entends souvent dire que nous devons fournir le service parfait, que nos clients attendent de nous la perfection, que le client n’acceptera rien d’autre qu’une solution parfaite. Cela se présente de différentes manières, mais il est toujours question perfection.

Ouais … en fait cette perfection me rend fou. Non, pour être honnête, ce sont plutôt les individus qui la défendent aveuglément qui me fatiguent. Ils ne pourraient pas être plus dans le faux. Ils sont si loin d’une approche pragmatique.

Qu’est -e que la perfection ?

On s’en fout.

Quelle devrait être la bonne question?

Comme il existe autant de définitions de la perfection que de perfectionnistes dans ce monde, nous devons nous concentrer sur quelque chose de plus utile. Essayons des questions telles que « de quoi notre client avait-il besoin? » ou « quel est le réel besoin de notre client? » ou même « quelle pourrait être la valeur ajoutée minimale que nous pouvons apporter à notre client pour le rendre heureux? »

La plupart du temps, lorsque nous trouvons la vraie réponse à une de ces questions, nous nous apercevons que nous sommes très loin de ce que nous pensions être la perfection.

Oui, il serait si génial de pouvoir livrer cette dite perfection. Sans aucun doute. Mais c’est tout simplement impossible et essayé de s’en approcher, c’est perdre du temps et de l’argent pour un gain trop ténu.

L’écart

Pour comprendre ce que je dis, considérons simplement que ce que nous visons dans notre organisation est un « bon » ou un « très bon » niveau de satisfaction.

Avec de très bons services, nos clients sont satisfaits. Ils peuvent faire leur travail et ne remarqueraient même pas une erreur non bloquante ou s’ils le faisaient, cela ne les empêcherait pas de travailler comme ils le souhaitent. Disons que cela représente 90% de ce que nous pouvons faire ou de ce à quoi le client peut s’attendre.

Atteindre la perfection signifie essayer de remplir les 10% restants (la perfection devrait être 100%, non?).

C’est ici que nous avons un problème selon moi, car le temps, l’argent et l’énergie que nous allons dépenser pour ajouter ce petit élément sont disproportionnés par rapport à la différence que ces 10% vont réellement faire sur l’impression finale du produit par le client.

Bien sûr, il y a toujours de la place pour faire mieux, mais à quel coût pour quel gain?

Conclusion

La perfection est un idéal et en tant que tel est donc inatteignable, alors la demander comme résultat tangible d’un travail est une aberration. L’effort nécessaire pour « satisfaire » l’entêtement à atteindre cette perfection est disproportionné par rapport à la différence entre la perception du « très bien » et du « parfait ».

Alors, concentrons nous sur une qualité très haute sans y inclure la perfection et dans la très très très très grande majorité des cas, le client final sera plus que satisfait.

Le pinailleur perfectionniste restera un éternel insatisfait, donc ne perdons pas notre temps.

Aller, A+