Scrum : éléments à considérer lors d'un lancement de sprint

Photo by Braden Collum on Unsplash
Dans ce court article, je décris la structure que je recommande pour lancer un sprint en pensant à tous les éléments en jeu. L'idée est venue, car j'observe qu'on démarre, par réflexe et enthousiasme sûrement, sur les nouveautés côté métier, les user stories. Cependant, il n'y a pas que la course à la nouvelle fonctionnalité dans un projet informatique !
  1. 1) Est-ce qu’il y a des congés, séminaires, formations, fériées … bref, des événements connus qui vont impacter sur la capacité de l’équipe à réaliser de la valeur métier. Ou comme on me l’a rappelé, il faut aussi anticiper ce qui va prendre de l’énergie, par exemple la mise en production (MEP) d’une autre équipe qui impacte le logiciel réalisé par notre équipe (gestion de dépendance).

  2. 2) R.A.F. - Est-ce qu’il y a, “malheureusement”, du Reste A Faire (et non pas du rien à foutre) qui vient du sprint précédent ?

  3. 3) Si vous n’avez pas une politique du 0 défaut dans le code (0 bug policy), ou une équipe qui ramasse les petits besoins de votre équipe (équipe de maintenance, les petits bonshommes verts du logiciel), est-ce qu’il y a des bugs critiques ou majeurs à régler dans ce sprint ?

  4. 4) Puisqu’on est d’accord, des rétrospectives sans actions dans les jours qui suivent, ça ne sert à rien. On risque de transformer la rétrospective, si critique dans l’agilité d’une équipe, en un bureau des pleurs. On planifie le top 1 à 5 actions SMART à mettre en place pour s’améliorer.

  5. 5) Même s’il est souhaitable d’intégrer des travaux techniques dans les user stories, il se peut qu’on doive mettre sa cravate en tant qu’ingénieur et qu’on décide de remonter une alerte au Product Owner (ex. problème de performance anticipé, refactoring d’une zone de code non maintenable). Certaines équipes appellent cela les technical stories. Bref, faites l’effort au maximum pour tourner ça en gain pour l’utilisation. Par exemple, amélioration de 1 seconde perçue par l’utilisateur de notre application mobile lors du chargement de la page.

  6. 6) Enfin, on parle de valeur métier, de user stories ! On prend la pile ordonnée par valeur métier (backlog) par la ou le product owner. Lors de la Sprint Review, vous avez certainement récolté du feedback sur les User Stories démontrées. Le/la Product Owner aura mis à jour le Backlog en fonction des ajustements à faire au préalable. On exprime alors, en équipe, le niveau de confort qu’on a à réaliser le top X user stories sans se mettre la corde au cou, en considérant la capacité de l’équipe qui risque d’être affectée par les 5 premiers points listés ci-dessus.

  7. 7) On trouve un titre ou objectif du sprint comme recommandé par le guide Scrum, le pourquoi on va se lever le matin pendant cette itération. Dans la foulée, les équipes ou parties d’équipe peuvent découper en sous-tâches les éléments du sprint backlog nouvellement formé.

A noter que je n’ai pas écrit que la ou le product owner attribue des éléments du backlog à des membres de l’équipe. A l’équipe de s’auto-organiser et se responsabiliser pour le reste de l’itération.

Merci Fleur, Sanaa, Souad, Bastien et Pierre pour la relecture et l'amélioration de cet article !