Agile et efficace : Comment les user stories contribuent au succès des sprints

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Bill Cronin
Source : Agile and efficient: How user stories power successful sprints
Date : 30/01/2015


Traducteur : Fabrice Aimetti
Date : 25/02/2019


Traduction :

Bills-blog-images 18 1.jpg

Chez Devbridge, lorsque nous travaillons avec nos clients pour définir un backlog produit, un product owner collabore avec les parties prenantes, les concepteurs et les développeurs du client pour définir les exigences du produit sous la forme de "user stories". Ces user stories sont regroupées en un ensemble de features et d'epics pour constituer un backlog de release (~version) du produit.

Une fois qu'un backlog de release est rempli de user stories, nos équipes de conception et de développement travaillent à estimer chaque user story à l'aide d'une unité de mesure appelée "points de story". En additionnant toutes les user stories estimées dans une release, nous pouvons déterminer la taille totale de la release.

Une release est décomposée en sprints, ou itérations de deux semaines de livrables pour obtenir un incrément produit. Au cours d'un sprint, l'équipe de développement s'engage à livrer un ensemble de user stories pendant cette période de deux semaines. Un sprint n'est considéré comme réussi que lorsque les critères suivants sont remplis :

  • L'équipe livre toutes les user stories engagées
  • Toutes les stories sont acceptées par le product owner
  • L'équipe fabrique un incrément produit ayant une valeur ajoutée et démontrable pour le client.
  • L'équipe n'est pas émotionnellement en vrac ou meurtrie au cours du processus.

Le succès ou l'échec des sprints peut avoir un impact significatif sur la date de release d'un produit et le coût total du projet. Chez Devbridge, nous utilisons des tactiques simples pour garantir le succès des sprints. Les suggestions ci-dessous sont des recommandations basées sur notre expérience dans le développement de logiciels Agile. Faites preuve d'adaptabilité. Soyez agile. Utilisez ce qui fonctionne le mieux pour vous.

Prendre en compte toutes les activités techniques

Le problème le plus courant que nous rencontrons avec les clients est lorsqu'une équipe ne prend pas correctement en compte les technical stories. Tout comme un peintre ne peut pas commencer à peindre sans d'abord acheter de la peinture et des pinceaux, coller les décorations murales et poser des toiles de protection, les développeurs et les testeurs doivent préparer et entretenir leur espace de travail en mettant en place les environnements de la solution, des référentiels de code, des serveurs d'intégration continue et en corrigeant des bugs. Tous ces efforts prennent du temps et doivent être pris en compte.

Bills-blog-images 03 1.jpg

Tout comme les user stories, les technical stories doivent également donner lieu à une estimation de l'effort. Sans le suivi des technical stories, le backlog ne représentera pas fidèlement l'effort total requis pour une release et entraînera en fin de compte des prévisions de livraison inexactes. Ce problème apparaît dans les sprints lorsque les équipes de développement passent du temps à faire des tâches qui ne sont pas représentées dans le backlog, tout en ne finissant pas non plus les stories qui sont engagées dans le sprint. À moins que vous ne vouliez renverser de la peinture partout, assurez-vous de prendre en compte l'effort nécessaire pour déposer votre toile de protection et de suivre les technical stories de votre équipe.

Conservez des stories de petite taille

Au cours des cérémonies de planification du sprint, l'équipe est responsable de déterminer quelles user stories livrer lors du sprint à venir. Les user stories sont généralement estimées en story points à l'aide d'une séquence de Fibonacci simplifiée (1, 2, 3, 5, 8, 13, 20, 40, 100). Cette approche facilite l'estimation rapide des user stories sans entrer dans un débat visant à définir l'effort exact en heures.

Pour garantir le succès des sprints, n'acceptez pas de user stories d'une taille de plus de 13 points dans un sprint. Lorsqu'une équipe rencontre une user story de plus de 13 points, soit la story peut être découpée en plusieurs petites user stories, soit l'équipe ne comprend pas suffisamment la story pour la prendre dans le sprint. Tout comme les poupées russes, une user story peut presque toujours être découpée en petits entités.

Bills-blog-images 07 1.jpg

Par exemple, une story de 20 points pourrait être divisée en deux stories : une story en 13 points et une autre en 8 points. Dans le cas où une user story ne peut pas être facilement découpée en stories plus petites, il est probable que l'équipe ne comprend pas entièrement la story. Dans ce scénario, envisagez d'ajouter un technical spike au sprint pour évaluer la meilleure façon d'aborder la story, puis déplacez la story incassable dans le sprint suivant. Cette approche garantit que vous ne commencez que des user stories que l'équipe comprend parfaitement, ce qui augmente le taux de stories finies et réduit l'envie de fractionner les stories partiellement terminées.

Ne pas comptabiliser les points des stories partiellement terminées

En termes simples, une story n'est pas terminée tant qu'elle ne l'est pas complètement. Si l'équipe s'engage sur une story de 13 points dans un sprint, et qu'elle ne remplit que la moitié des critères d'acceptation de cette story, toute la story doit être déplacée dans le sprint suivant. Ne la passez pas à "Go". Ne touchez pas les 200$. Découper une user story et comptabiliser une partie des points, c'est comme prendre des vacances, arriver à destination, récupérer vos bagages et découvrir que la moitié seulement de vos bagages ont été transportés.

Découper les user stories et gagner une partie des points génèrent un biais comportemental qui ne devrait pas être encouragé : récompenser une équipe pour des stories incomplètes. Récompenseriez-vous une compagnie aérienne qui a perdu la moitié de vos bagages ? Si la user story avait pu être partiellement terminée, elle aurait dû être découpée en stories plus petites lors de la cérémonie de planification du sprint.

Cette approche est également importante parce qu'elle indique quand vous devez corriger la vélocité du sprint de votre équipe. Votre équipe croit qu'elle a assez de vélocité pour terminer une story en 13 points, mais elle n'a manifestement pas la bande-passante disponible. En retirant 13 points de la vélocité du sprint et en planifiant de livrer 13 points de moins lors de votre prochain sprint, vous corrigez un excès de vélocité de l'équipe et vous augmentez les chances de succès pour les sprints futurs.

Mettre en oeuvre des limites des WIP

Faisons un exercice rapide. Prononcez chaque lettre de l'alphabet dans votre tête, puis comptez les chiffres de 1 à 26 dans votre tête. Allez-y, essayez de le faire.

Combien de temps cela vous a-t-il pris ?

Prononcez maintenant chaque lettre de l'alphabet dans votre tête en énumérant le nombre correspondant (1A, 2B, 3C, etc.).

Arrivez-vous à le faire ?

La plupart des gens ne peuvent pas. Parce que les humains sont très mauvais quand il s'agit de faire fonctionner notre cerveau en multitâches (charge cognitive plus élevée). Le changement de contexte entre les tâches est l'une des plus grandes pertes de temps dans le développement de logiciels. Pour cette raison, il est important de limiter le nombre de user stories sur lesquelles un membre de l'équipe travaille à un moment donné pendant un sprint. Cela signifie que les développeurs et les testeurs ne doivent pas travailler sur plus d'une ou deux user stories à la fois, sinon ils risquent de passer trop de temps sur chaque user story.

Bills-blog-images 12 1.jpg

Graphique tiré du livre de Mike Cohn : Agile Estimating and Planning.

Une équipe peut réduire le nombre de user stories actives en mettant en place des "limites de travaux en cours", souvent appelées "limites de WIP" (Work In Progress). Ces limites mettent l'accent sur la livraison, mettent en évidence les goulots d'étranglement, réduisent le changement de contexte et empêchent les développeurs de commencer des stories qu'ils ne peuvent pas terminer. Les limites de WIP sont de loin l'outil le plus efficace dans votre arsenal pour assurer le succès des sprints.

La taille compte vraiment

Nous savons tous qu'il faut établir l'ordre de priorité des stories du backlog en fonction de la valeur métier vue des clients, mais qu'en est-il de la taille des stories ? Si nous ne commençons pas les grosses stories assez tôt dans le sprint, nous avons moins de chances de les terminer. Nous ne pouvons pas non plus comptabiliser une partie des points de stories partiellement terminées, il est donc important de s'assurer que les stories les plus importantes sont terminées en premier.

Le résultat c'est que les stories de plus grande taille reçoivent automatiquement une priorité plus élevée dans le backlog des sprints. Cette approche vous oblige à prendre en compte le nombre de grosses user stories à engager dans un sprint, et réduit le besoin de découper les stories partiellement terminées.

Combien de temps vous faut-il pour vous rendre à pied de chez vous au parc le plus proche ? Et de l'autre côté de la ville ? Qu'en est-il à l'échelle du pays ? Dans quelle mesure faites-vous confiance à chaque estimation ? Au fur et à mesure que l'effort requis pour une tâche augmente, la confiance et l'exactitude des estimations diminuent. Cela signifie que les user stories de plus grande taille sont plus susceptibles de prendre plus de temps à terminer que ce que nous percevons.

Bills-blog-images 14 1.jpg

Graphique tiré du livre de Mike Cohn : Agile Estimating and Planning.

En limitant la taille des stories et le nombre de grosses stories que vous incluez dans un sprint, vous pouvez réduire le risque d'échouer sur un sprint.

Examinez les stories au fur et à mesure qu'elles sont terminées

Supposons que vous vouliez commander de délicieuses pizzas de Chicago, mais que vous recevez à la place une mini pizza bagel surgelée. Êtes-vous heureux ? Je veux dire, la pizza c'est de la pizza, non ? Pensez-vous que vous auriez pu remédier à cette mésaventure si vous aviez vu le chef préparer votre pizza ?

La formation traditionnelle Scrum laisse entendre que l'équipe de développement présente des stories terminées au product owner à la fin du sprint lors de la cérémonie de revue du sprint. En théorie, cela peut sembler raisonnable, mais en pratique, il s'agit d'une mini pizza bagel en attente. La fin du sprint laisse peu de temps au product owner pour fournir un feedback utile à l'équipe. Les user stories qui ne sont pas acceptées par le product owner sont considérées comme incomplètes et, par conséquent, le sprint échoue. Pour garantir le succès des sprints, ajoutez une étape de revue à votre processus de développement afin d'obtenir les feedbacks en temps réel de la part votre product owner lorsque les stories sont terminées.

Modifier la durée de votre sprint

Chaque échec est une occasion d'apprendre et de s'améliorer. À la fin de chaque sprint, votre équipe devrait faire une rétrospective du sprint pour évaluer ce qui s'est bien passé, ce qui ne s'est pas bien passé et les initiatives que votre équipe peut prendre pour s'améliorer.

Si les sprints de votre équipe échouent, faites-les échouer plus rapidement pour que vous puissiez apprendre plus tôt. Si votre équipe déroule des sprints de deux ou trois semaines, envisagez de dérouler des sprints d'une semaine pour itérer plus rapidement sur les améliorations.

Obtenir de l'aide

Vous avez toujours du mal à obtenir des sprints réussis de la part de vos équipes ? Envisagez de faire appel à Devbridge pour son expertise en conseil Agile et en génie logiciel.