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