La décomposition des Epics
Un formateur Scrum m'a récemment demandé quelques bons exemples où de grandes User Stories (Epics) ont été découpées en Stories plus petites. Je souhaite partager ces exemples avec vous.
Epic 1 : Trouver la bonne campagne marketing
Le premier exemple concerne une entreprise qui vend des logiciels à de grandes enseignes de distribution (WalMart, etc.). Le responsable du département marketing devait décider comment dépenser le budget publicitaire. C'est pourquoi la User Story (Epic) a été rédigée de son point de vue. Son premier grand objectif était :
En tant que responsable du département marketing, je souhaite pouvoir consulter les campagnes publicitaires passées afin d'identifier et de reproduire les campagnes les plus rentables.
Les membres de l'équipe ont dit qu'il s'agissait clairement d'un Epic. Je leur ai donc demandé d'en faire plusieurs stories plus petites :
1a : En tant que responsable du département marketing, je souhaite pouvoir sélectionner une période pour les campagnes publicitaires à examiner, afin que…
2a : En tant que responsable du département marketing, je souhaite pouvoir choisir quelles campagnes (publipostage, TV, e-mail, radio, etc.) doivent être incluses dans l'examen, afin que…
(Notez que j'ai numéroté les stories de manière à pouvoir identifier de quelle story originale elles proviennent. Dans un vrai projet, je ne ferais pas nécessairement cela – sauf si j'avais un outil qui le fait automatiquement.)
Je ne savais pas exactement quelle taille avaient ces deux stories et s'il fallait les découper encore une fois. J'ai donc demandé à l'équipe : "Si vous deviez estimer ces stories, quelle unité vous viendrait en premier à l'esprit ? Heures, jours, semaines, mois ou années ?" Pour la 1a, c'était des jours, donc la story est restée telle quelle. Pour la 1b, c'était des semaines, c'est pourquoi nous avons subdivisé la story encore une fois :
1b1: En tant que responsable du département marketing, je souhaite pouvoir consulter les informations sur les publipostages des campagnes précédentes, afin de…
1b2: En tant que responsable du département marketing, je souhaite pouvoir consulter les informations sur les publicités TV des campagnes précédentes, afin de…
1b3: En tant que responsable du département marketing, je souhaite pouvoir consulter les informations sur les campagnes précédentes de publicité par e-mail, afin de…
etc.
Chacune de ces stories avait une bonne taille ("nous estimerions cette story en jours"). Cependant, elles nécessitaient encore certaines informations – les fameuses "Conditions of Satisfaction", qui sont essentiellement des tests d'acceptation de haut niveau. Pour 1b2, les membres de l'équipe ont écrit ce qui suit au dos de la fiche :
Combien de spectateurs de chaque tranche d'âge y avait-il ?
Combien de spectateurs de chaque tranche de revenus y avait-il ?
Exemple 2 : Maximisation du chiffre d'affaires d'un hôtel
Dans cet exemple, il s'agit d'un hôtel dont on voulait maximiser le chiffre d'affaires, c'est-à-dire que l'exploitant souhaitait trouver le prix le plus élevé possible pour les chambres d'hôtel. Les prix étaient calculés en fonction de plusieurs facteurs. Il s'agissait par exemple des tarifs de chambres d'hôtels comparables, de la saison, de grands événements à proximité (quand le Super Bowl ou une coupe du monde se déroule dans une ville, les prix y augmentent), etc.
Voici la User Story originale (Epic) :
1 : En tant qu'hôtelier, je souhaite trouver le prix optimal pour mes chambres d'hôtel.
Pour simplifier, nous partons du principe que l'hôtel ne dispose que d'une seule catégorie de chambres. Comme mentionné précédemment, de nombreux facteurs peuvent influencer le prix d'une chambre d'hôtel. La formule de base pour le calcul du prix de la chambre est alors la suivante :
Prix de la chambre = f (a,b,c…)
Cette fonction dépend de différents facteurs. Pour chacun d'entre eux, il existe une Story :
1a : En tant qu'hôtelier, je souhaite fixer le prix optimal de mes chambres d'hôtel en fonction des prix de l'année dernière.
1b : En tant qu'hôtelier, je souhaite fixer le prix optimal de mes chambres d'hôtel en fonction des prix d'hôtels comparables.
La Story 1a indique simplement que les prix de l'année précédente sont pris en compte dans la fonction. La Story 1b indique que les prix pratiqués par d'autres hôtels sont également inclus dans le calcul.
Chacune des Stories était relativement grande (un Epic) et bien sûr, il y avait plus que les deux Stories mentionnées ci-dessus. Il aurait donc été impossible de toutes les intégrer dans un seul Sprint. Les Stories ont été implémentées progressivement et ainsi, la formule mentionnée donnait un prix erroné, car elle était construite de la manière suivante :
Prix de la chambre = f (a)
puis
Prix de la chambre = f (a,b)
puis
Prix de la chambre = f (a,b,c)
etc.
Après le premier Sprint, le calcul serait donc Prix de la chambre = f (a) et on obtiendrait un prix erroné (qui ne peut pas être communiqué au client). Cependant, le calcul en lui-même est fondamentalement correct. Peut-être que les valeurs pour (b) et (c) sont codées en dur ou simplement ignorées. Mais de cette manière, de tels algorithmes complexes peuvent être construits de façon incrémentale.
Comme la Story 1b était encore trop grande, elle a été à nouveau subdivisée :
- 1b1 : En tant qu'hôtelier, je peux définir un certain nombre d'hôtels comparables. (Le terme "Comparable Set" était utilisé dans cette entreprise.)
- 1b2 : En tant qu'hôtelier, je peux ajouter des hôtels au Comparable Set.
- 1b3 : En tant qu'hôtelier, je peux retirer des hôtels du Comparable Set.
- 1b4 : En tant qu'hôtelier, je peux supprimer un Comparable Set complet dont je n'ai plus besoin.
- 1b5 : En tant qu'hôtelier, je m'oriente sur les prix des chambres des hôtels d'un Comparable Set spécifique pour déterminer mes prix de chambres.
Voici deux Stories supplémentaires :
- 1c : En tant qu'hôtelier, je souhaite ajuster le prix optimal de mes chambres d'hôtel en fonction du taux d'occupation prévu.
- 1d : En tant qu'hôtelier, je peux définir des paramètres qui influencent le prix optimal, comme le taux d'occupation souhaité, l'occupation minimale et l'occupation maximale (pourrait dépasser 100 %).
Conclusion sur le découpage des Epics
Presque toutes les équipes ont des difficultés au début pour découper correctement les User Stories. L'expérience montre qu'à un moment donné, au cours de la première année, le déclic se produit et les membres de l'équipe savent alors comment découper les Stories spécifiquement pour leur domaine d'expertise et leurs projets. Si tu n'es pas encore très familier avec Agile ou les User Stories, persévère – avec le temps, cela deviendra plus facile !