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 !
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).
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 ?
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 ?
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.
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.
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.
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.
