Plus une story est grosse et plus c'est indigeste : la théorie du hamburger

Tout au long d'un projet agile, l'équipe se réfère au product backlog. C'est le Product Owner qui est maître du document. Il peut le faire évoluer d'un sprint à un autre. Aider le product owner à le concevoir et le faire vivre demande de la pédagogie. Objectif : avoir des stories indépendantes, claires et suffisamment petites pour être facilement évaluées, traitées et garantir la bonne progression du projet.

LA PREMIÈRE FOIS QUE J'AI ENTENDU PARLER DE LA THÉORIE DU HAMBURGER : LE CONTEXTE

J’étais sur un projet d’application web. Nous étions presque à la fin du sprint 1 (d'une durée de 3 semaines), et l’équipe (3 développeurs) était toujours en train de travailler sur la première story.
Je me suis rendue compte que les user stories transmises par le product owner étaient bien trop grosses. L’équipe avait l’impression de ne pas avancer, la valeur totale produite sur le sprint était faible, le product owner déçu de ne pas voir l’intégralité du périmètre réalisé, le nombre de tâches largement sous évaluées et surtout les story ressemblaient à des fourre-tout avec des éléments indispensables et d’autres non.
Un collègue Scrum master m’a alors expliqué cette théorie. Une histoire de steak et de salade…

DE QUOI EST COMPOSÉ UN HAMBURGER

Décomposons un hamburger classique : on a une tranche de pain inférieure, une tranche de steak, des tomates, de la salade, une tranche de fromage, des oignons et une tranche de pain supérieure.
A-t-on forcément besoin de tous ces ingrédients pour appeler un sandwich « hamburger » ? Non. A partir du moment où l’on a deux tranches de pain et une tranche de steak, on peut considérer que le sandwish s'appelle hamburger. Le reste ne sert qu’à l’améliorer, le personnaliser, le rendre original. Mais, seules les tranches de pain et le steak sont strictement indispensables.

DE LA COMPOSITION DU HAMBURGER À LA COMPOSITION D’UNE USER STORY

Charles est product owner. Il construit sa user story comme il prépare un hamburger : avant de la rédiger, il se demande ce qui est strictement nécessaire à la fonctionnalité souhaitée. Les éléments non indispensables peuvent être dissociés et intégrés à une prochaine story.

Prenons l’exemple suivant : Charles souhaite mettre en place une fonction d’administration des utilisateurs sur son site internet. Sa story doit comprendre a minima la création d’un utilisateur, l’accès à la liste des utilisateurs existants, la mise à jour de ces derniers et la suppression. Sans ces quatre opérations, la fonctionnalité n’est pas viable. Un administrateur ne pourra pas être autonome dans l’administration de ses utilisateurs.
En revanche, il peut avoir dans un second temps une story qui lui permette de faire le tri par nom d’utilisateur, d’avoir un compteur des utilisateurs déjà crées, de mettre en place une pagination, d’avoir une info bulle décrivant les permissions de chacun des rôles…

SI L'INDISPENSABLE DE LA FONCTIONNALITÉ N'EST PAS RÉALISÉ, RIEN NE SERT DE PASSER DU TEMPS SUR LE SUPERFLU.

Bref, quand votre product owner vous transmet des story qui ressemblent au double royal cheese, faites-le simplement démarrer par un cheesburger.
Pour continuer dans les images culinaires, si j'ai ma tranche de pain supérieure, ma tranche de viande et du ketchup, et bien mon sandwich est immangeable. Je vais en avoir plein les mains !

C'est fou comme la majorité des product owner veulent absolument que l'équipe traite l'exhaustivité de la fonctionnalité dès que celle-ci est abordée. Pourtant il faut bien garder à l'idée que le but d'un projet agile est de pouvoir très rapidement avoir un produit utilisable. Rien n'empêche, par la suite, et si les conditions le permettent, d'améliorer l'expérience de l'utilisateur.

Il n’est pas naturel pour Charles de découper son besoin et de remplacer son cahier des charges initial en une série de stories dissociées les unes des autres. La théorie du hamburger m'aide à expliquer aux product owner comment découper leur besoin pour commencer par l’essentiel et finir ensuite par le non indispensable. De cette façon, on sécurise le projet en réalisant d'abord ce qui est vital pour l’utilisation de l’application.

Et vous, vous êtes-vous déjà retrouvés dans une situation où le product owner veut tout, tout de suite ?