Scrum Master Academy – Parlons des user stories

Voilà quelques temps que je n’ai pas publié une règle de la Scrum Master Academy et j’entends gronder la foule des lecteurs de ce blog qui s’impatientent sérieusement (dites-moi si je fabule). J’ai donc pris une grande décision pour d’une part assouvir votre curiosité, et d’autre part boucler plus rapidement cette série de billets qui commence à tourner au péplum : je vais vous divulguer les règles par petits paquets de 4 ou 5.

Les 4 règles de ce billet se focalisent sur un élément qui s’avère paradoxalement souvent mal maîtrisé lors d’une réalisation d’un projet agile : les user stories. Ce n’est pas à proprement parler un élément du framework Scrum, cette pratique nous vient de l’Extreme Programming, mais elle est largement utilisée dans le cadre de projets menés en Scrum au point de devenir la référence de nombreuses formations certifiantes. Les user stories paraissent à première vue simple et à la portée de tous, c’est d’ailleurs exactement ce qu’on leur demande : simplicité et concision. Si vous n’êtes pas encore familier avec la notion de user story, on en trouve de nombreux exemples sur le web, la forme la plus populaire étant le modèle:

En tant que <rôle>

Je veux <faire quelque chose>

Dans le but de <obtenir de la valeur>

Mais même ce modèle simpliste peut être mal utilisé, voilà quelques difficultés que j’ai pu rencontrer :

  • faut-il exprimer un besoin ou une solution ? Je constate que plus la personne qui rédige la story est éloignée du développement informatique, plus la story est exprimée en termes de besoin à un niveau abstrait. De même, lorsque la dimension exploratoire du produit développé est très forte, on a tendance à formuler des besoins plus que des solutions. La réponse n’est pas si claire et chacun ira de sa recommandation en fonction de son vécu.
  • comment mesurer la valeur métier ? C’est souvent difficile à mesurer voire intangible, et par conséquent on se retrouve parfois avec des stories de ce genre : En tant qu’utilisateur je veux supprimer un enregistrement dans le but d’effacer un enregistrement.
  • détournement du modèle pour exprimer une story technique : parfois le Product Owner n’exprime pas des stories qui paraissent fondamentales pour l’équipe de développement, ces derniers glissent donc dans le backlog des stories de ce genre : En tant que développeur je veux avoir un outil d’intégration continue dans le but de mieux faire mon travail.

J’aime la définition suivante (qui n’est pas de moi bien sûr):

Une user story est une invitation à avoir une conversation avec son client sur un sujet particulier

Cette définition a le mérite de recadrer l’utilisation de stories techniques : quelle genre de discussion allez-vous avoir avec votre client sur la plateforme d’intégration continue ou la migration du modèle de données ? Elle a aussi le mérite de préciser l’objectif de la user story : la conversation. Ce n’est donc ni un besoin, ni une solution, c’est une conversation. Ces caractéristiques se retrouvent dans les caractéristiques des 3C ou l’acronyme INVEST, qui sont les références à garder à l’esprit pour exprimer de bonnes user stories.

Toutes ces difficultés décrites plus haut nous ont amené à exprimer les 4 règles suivantes qui globalement tendent toutes vers le même objectif : une bonne collaboration entre l’équipe technique et le donneur d’ordre.

Règle n°4 : N’oublie jamais la valeur d’une story

Cette règle vise 3 objectifs pour notre Scrum Master : assister le Product Owner pour la gestion de son backlog, éviter l’inondation de stories techniques dans le backlog, et guider l’équipe lors du découpage de stories trop grosses. La partie « dans le but de… » est souvent lésée lors de l’expression des stories. Soit parce que la valeur nous paraît (trop) évidente, soit parce qu’inversement la valeur est très difficile à estimer en argent sonnant et trébuchant. Dans les 2 cas, on peut appliquer quelques trucs simples pour estimer la valeur. D’une part, on peut considérer que la valeur d’une story est proportionnelle aux nombre de parties prenantes qui la demandent, qu’ils soient utilisateurs, managers, commerciaux, dirigeants… On peut ainsi suggérer à son Product Owner d’inviter les différentes parties prenantes à faire un poker planning de business points, ou bien à participer à un atelier Buy-a-Feature. D’autre part on peut également estimer la valeur d’une story en terme de risque de ne pas faire. Cette dernière s’applique souvent pour les stories qui découlent d’obligations réglementaires, mais on peut l’étendre à n’importe quel type de stories.

Règle n°5 : Une story trop grosse pour entrer dans un sprint est une Epic

Cette règle est un simple rappel de ce que l’on enseigne classiquement dans un cours Scrum ou une formation agile. Il nous paraît cependant nécessaire de le rappeler car ce n’est pas forcément toujours bien appliqué. On pourrait en fait reformuler cette règle de la manière suivante: si la story est trop grosse pour être développée en un seul sprint, ce n’est pas une story. L’intérêt de cette règle est surtout ce qu’elle sous-entend: le découpage des stories trop grosses. Une Epic ne peut pas être traitée comme telle par l’équipe de développement, il faut la découper en unités plus petites qui vont rentrer totalement dans un sprint. Ici je me retrouve parfois confronté à la situation où le PO, ou l’équipe, considère qu’on ne peut pas découper plus finement certaines stories et découpent donc la story en tâches techniques planifiés sur 2 sprints. Pourtant il existe de nombreuses stratégies,ici ou ici, pour descendre à un niveau encore plus fin sans tomber dans le découpage techniques (se reporter à la règle n°4 si vous êtes tentés par l’expérience).

Règle n°6 : Il faut pouvoir prendre plus de 4 stories par sprint

Vous ne trouverez sans doute pas mention de cette troisième règle dans la documentation Scrum classique. C’est une règle de routards de l’agilité, issue de l’expérience, dont la paternité revient à Jean-Laurent. Cette règle va encore plus loin que la précédente dans la mesure où elle nous demande de découper les stories à un grain suffisamment fin pour en prendre plus de 4 dans un sprint. J’irai même plus loin, il faut qu’un développeur puisse travailler sur plus qu’une story pendant le sprint. Si une story occupe un développeur sur la totalité du sprint, il se crée un effet tunnel qui risque de mettre le sprint en péril. Jean-Laurent l’explique de la manière suivante: les estimations c’est un peu le jeu des devinettes. Nous savons qu’elles sont globalement vraies mais précisément fausses. Cette marge d’erreur peut conduire à ne pas pouvoir terminer une story dans le sprint où nous la planifions. Si vous ne prenez que 4 stories dans un sprint et que vous n’en terminez pas une, c’est 1/4 de l’objectif qui n’est pas réalisé. Ce qui est relativement important, à plus forte raison si la story est de taille importante. N’hésitez pas à redécouper vos grosses stories même si elles tiennent dans un sprint. Cela facilitera le suivi, les tests, et le niveau de confiance sur l’atteinte des objectifs du sprint.

Règle n°8 : À la fin du sprint il y a 2 options pour une story : « done », ou « not done »

Ici aussi c’est une règle évidente qui est enseignée dans de nombreuses formations agiles. Et pourtant les tentations d’y déroger sont nombreuses : « il ne reste plus qu’à intégrer », « on y est presque », « on n’a pas testé mais j’ai confiance », « on n’a qu’à dire que c’est done et on ajoutera des tâches techniques sur le sprint suivant ».

Toutes ces tentatives de passage en force mettent à mal la Définition du Done (DoD), qui est pourtant un élément essentiel de confiance entre le PO et l’équipe. C’est également un élément de mesure dans Scrum car elle contribue au calcul de la vélocité. Mettre à mal sa DoD est une promesse de complications à court terme. Que faire alors avec ces stories « not done » ? Normalement on les planifie sur le sprint suivant, mais faut-il reporter l’intégralité des points alors que la moitié du travail est déjà fait ?

Voilà la manière dont je fonctionne : oui je reporte totalement les points, quel que soit l’état d’avancement des stories concernées. Bien souvent, celles-ci avaient de toute façon été sous-estimées. Si l’on ne reporte pas les points, on risque de sous-estimer le contenu du sprint suivant, et donc de se retrouver à nouveau avec des stories non terminées. Et progressivement, sprint après sprint, on se construit un matelas de stories « not done » qui prend du volume. Très vite, la vélocité ne signifie plus rien, donc les projections ne signifient plus rien, donc le PO ne comprend plus l’avancement, et tout ça risque de se terminer en un vaste règlement de comptes.

Pour résumer : je ne compte pas une story « not done » dans la vélocité constatée d’un sprint, et je la compte entièrement dans les points prévus pour le sprint suivant, sachant que ce total de points doit être toujours cohérent avec la vélocité constatée des derniers sprints. Cette méthode peut paraître un peu radicale (ou inutile pour les détracteurs de la vélocité), mais si vous appliquez bien la règle n°6, l’impact ne sera jamais vraiment significatif car toutes vos stories prises dans le sprint sont suffisamment petites pour éviter les grosses variations de vélocité.

A venir:

  • Règle n°7 : l’énergie de l’équipe c’est toi qui l’apporte
  • Règle n°10 : Dans une réunion ta place est debout à côté du paper board
  • Règle n°18 : L’auto-organisation nécessite du Leadership
  • Règle n°29 : Tu es un facilitateur pas un dictateur

4 commentaires

  • faut-il exprimer un besoin ou une solution ?

    Good question!

    Idéalement, il devrait y avoir uniquement 2 types de US.
    1° Les US purement « besoin »: « En tant qu’utilisateur client je veux identifier mes factures impayées »
    Dans le cas présent, la taille de la US n’est (à mon avis) pas « atomique » et peu potentiellement donné lieu à plusieurs solutions et donc plusieurs US.

    2° Les US « solution + besoin »: « En tant qu’utilisateur client, je veux afficher la liste de mes factures afin d’identifier les factures impayées »
    La partie « afin de … » permet de forcer le PO à exprimer le besoin initial et c’est pourquoi il est important qu’il se force à le préciser autant que faire se peu!

    D’après moi, il faut à tout pris éviter les US sans explicitations du besoin pour les raisons suivantes:

    1° Si on ne connaît pas le besoin, on n’est pas sûr que la solution rapporte effectivement de la valeur mais surtout, on n’est pas sûr que la solution répond au besoin!

    2° Si l’équipe ne connaît pas le besoin (=le contexte), il y a des chances que l’interprétation « implicite » de l’équipe soit désynchronisée avec les notions implicites du PO

    3° L’équipe doit aussi être force de proposition dans les solutions proposées. Ces solutions peuvent être soit plus ergonomiques (car l’équipe propose des solutions techniques d’IHM que le PO ne connaissait pas ou n’avait pas envisagé) et/ou plus économiques (car en proposant une solution plus simple à un besoin, il sera possible d’embarquer une autre US)

    Enfin, si on reprend la définition: « Une user story est une invitation à avoir une conversation avec son client sur un sujet particulier », alors il me semble plus simple d’engager la conversation sur un besoin (= »question ouverte) plutôt que sur une solution (= »question fermée).

  • Bravo Gilles pour ce billet qui recadre de manière très juste les aspects importants des user stories!
    Comme disent les jeunes : je plussoie à l’aspect « besoin versus solution ». En fait l’utilisateur émet souvent ce « qu’il pense être une solution ». C’est déjà un premier travail à faire que de faire une petite analyse causale pour remonter le fil d’Ariane afin d’arriver au vrai besoin. Ca fait la différence entre une vraie US et un gribouillis produit avec les pieds. Et le fait que ce soit écrit sous la forme « en tant que X je veux Y afin que Z » n’y change rien !
    Merci aussi de recadrer les user stories par rapport à Scrum ! Effectivement, les deux sont de plus en plus associés, mais Scrum parle à l’origine de « backlog items ». Donc une question (et un sujet pour toi, Gilles) : le backlog doit-il ne présenter que des US ou des items qui peuvent être des US pour ce qui est fonctionnel et des items d’autre forme pour ce qui ne l’est pas (machins purement tech, léchage de bottes, peignage de girafe, etc…) ?
    Dernière chose : j’adore la formulation « les estimations sont globalement vraies mais précisément fausses » et j’aimerait la citer. Qui dois-je créditer pour cela : toi ou Jean-Laurent ?

  • Bonjour Christophe, merci pour ton commentaire éclairé. Ma compréhension du backlog Scrum c’est en effet une liste de machins, du moment que la valeur de chacun de ces machins est claire pour le PO. La user story, de part son format, est donc le meilleur moyen d’exprimer des machins plutôt clairs pour le PO sans être trop verbeuses.

    Concernant la citation elle n’est pas de moi, je l’ai piqué à un contrôleur de gestion qui nous expliquait son approche des budgets prévisionnels en démo de fin de sprint. Je me la suis appropriée car je trouvais que ça collait bien avec les estimations agiles.

  • Bonjour Montesq, merci pour votre commentaire. J’aime beaucoup votre principe de stories « solution + besoin ». Pour ma part j’essaye de pousser les PO à donner des éléments du contexte métier dans la partie « afin de  » de la story, ce qui revient au même.

Laisser un commentaire