Vous avez fait connaissance avec les différents membres de votre équipe. Ensemble, vous allez créer une application de réseau social. L’heure est venue de préparer le lancement du Sprint. Pour y parvenir, vous allez donc passer par trois étapes :
identifier et découper les tâches à traiter pendant le Sprint ;
quantifier l’effort alloué pour le traitement de chaque ticket ;
démarrer votre Sprint.
Participez au Backlog Refinement
Nous sommes lundi. Vous commencez tout juste votre semaine lorsque vous recevez un message de Samy. Il vous convie au Backlog Refinement. Il a réservé un créneau d’une heure de réunion aujourd'hui, entre 11 h et 12 h.
Vous rejoignez donc Anastasia, Jonathan, Samy et Garance : l’ensemble de l'équipe doit être présent. Garance introduit la réunion en présentant la User Story n° 1 517 du Product Backlog.
Avant de rentrer dans les détails techniques, Garance s’assure que cette User Story est bien comprise par tout le monde. Elle demande également l’avis de l’équipe sur sa faisabilité technique.
Ainsi, après 10 minutes d’échanges, le ticket est complété avec les informations ci-dessous :
Le ticket est validé par l’ensemble de l'équipe, Garance passe donc au suivant.
Jonathan, votre lead développeur, alerte Garance sur le traitement de cette User Story. Le service d'identification est en cours de développement par d’autres équipes, il ne peut pas être utilisé pour le moment. Vous passez les 10 minutes suivantes à chercher une solution à ce problème. Finalement, vous choisissez d'ajouter un ticket préliminaire à cette User Story, et de ne pas implémenter pour l’instant la fonctionnalité d'identification. Vous obtenez donc le ticket suivant :
Une fois ce découpage validé par l’ensemble de l'équipe, vous passez au ticket suivant.
Garance présente une User Story qui ne vous semble pas réalisable en l’état. Jonathan et Anastasia sont d’accord avec vous. Garance prend donc note de vos remarques : elle va retravailler la User Story et la présenter au prochain Backlog Refinement.
Participez au Poker Planning
Alors que vous travaillez avec Anastasia sur une nouvelle fonctionnalité du logiciel, vous recevez un message de Samy. Il vous propose de participer au Poker Planning, ou Scrum Poker, qui aura lieu mardi à 15 h.
Pendant le Poker Planning, toute l’équipe est réunie autour de la table, une carte à la main…
Une carte à la main ? Pourquoi faire ?
Rassurez-vous, on ne vous demande pas de faire un poker avec vos collègues. 😅 Les cartes servent ici de support pour la cotation des tickets. Chaque carte comporte un chiffre qui représente l’estimation du ticket. Ainsi, plus le chiffre est faible, plus le ticket est considéré comme étant peu complexe, ou rapide à traiter, et inversement, un ticket de forte valeur serait plus complexe, ou long à traiter.
Samy utilise la cotation Fibonacci, qui s'inspire de la suite de Fibonacci. Il s’agit d’une suite de nombres entiers dans laquelle chaque terme est le résultat de l’addition des deux nombres qui le précèdent : 1,2,3,5,8,13,21, etc. Cette méthode est souvent utilisée car elle offre un plus grand éventail de chiffres sur les cotations basses (1, 2, 3, 5) que sur les cotations les plus hautes (8, 13, 21, etc.).
Heuuu… En quoi c’est un avantage ?
Il existe cependant d’autres méthodes de cotation, comme la taille de T-shirt, par exemple (XS à XXL). Un ticket de taille “XS” sera donc considéré comme très peu complexe, tandis qu’un ticket XXL sera considéré comme très (très) complexe.
Très bien, mais pourquoi utiliser des cartes, alors ?
Pour que les autres membres de l’équipe ne puissent pas voir quelle carte vous choisissez. Ainsi, vous avez moins de risque d’influencer les autres lorsque vous faites votre estimation, et inversement. Une fois la User Story présentée par le Product Owner, chaque membre de l’équipe doit l’estimer individuellement en choisissant une carte. Dans votre équipe, les cartes correspondent à la valeur de la complexité estimée de la User Story. Ainsi, plus cette dernière vous semble complexe, plus vous choisirez une carte à forte valeur.
Laissez-moi vous expliquer ceci, en prenant l’exemple du ticket n° 1 517 !
Après avoir choisi individuellement une carte, chaque membre de l'équipe pose sa carte en même temps sur la table.
En ce qui vous concerne, vous avez estimé la complexité du ticket n° 1 517 à 5 points. Mais vous remarquez qu’Anastasia et Jonathan l’ont estimé à 3 points. Après quelques échanges, l’équipe vous a convaincu que le ticket était moins complexe que vous ne le pensiez. Il est finalement coté à 3 points.
Et voilà, les Story Points ont été ajoutés au ticket 1517 ! 😃
Vous passez ensuite en revue tous les tickets validés lors du Backlog Refinement.
Démarrez votre Sprint
Les tickets sont passés par le raffinement (Backlog Refinement), et ils ont été estimés par l'équipe ; il ne reste plus qu'à démarrer le Sprint ! 🥳…
Mais… Par quoi commence-t-on ?
Vous recevez un message de Samy qui vous convie au Sprint Planning. Il aura lieu mercredi dans la matinée. Lors de cette réunion, vous allez échanger avec l’ensemble de l’équipe. L’objectif est d’identifier les tickets à traiter pendant ce Sprint. Ainsi, vous récupérez les tickets que vous avez cotés précédemment (et éventuellement, les tickets non finalisés du Sprint précédent !).
L'équipe a identifié les tickets à traiter pendant le Sprint. L’ensemble est estimé à un total de 30 Story Points.
Garance présente le Burndown Chart (ou graphique d’avancement, en français) à l’équipe. C’est un support qui permet de visualiser les points restant à faire par l’équipe tout au long du Sprint.
Le graphique est composé de deux axes :
l’axe horizontal représente le nombre de jours dans le Sprint ;
l’axe vertical représente le nombre de points restant à effectuer dans le Sprint.
Samy relit l’ensemble des tickets validés, et conclut la réunion en énonçant le Sprint Goal (ou objectif du Sprint, en français). Cet objectif est formulé en une brève description, en une ou deux phrases, de ce que l'équipe doit accomplir pendant le Sprint. Il s’agit d’un objectif fixe qui ne peut être remis en cause au cours du Sprint. Samy communiquera le Sprint Goal aux managers et au client, pour qu’ils suivent les avancées du projet.
Profitez du retour d’expérience de développeurs agiles
Je vous propose de retrouver Benjamin Dasnois et Kassandre Pedro pour découvrir leur expérience à cette étape du Sprint.
En résumé
La préparation d’un Sprint repose sur différentes étapes réalisées en équipe :
découper techniquement les tâches du Product Backlog lors du Backlog Refinement ;
estimer la complexité technique ou le temps nécessaire pour traiter chaque ticket grâce au Poker Planning ;
prioriser et s’engager sur le traitement d’un nombre donné de tickets pendant le Sprint Planning ;
communiquer ces objectifs aux parties prenantes.
Vous venez de lancer votre premier Sprint, toutes mes félicitations ! 🥳 La prochaine étape : développer en mode agile !
