Un Sprint (appelé aussi une itération) correspond à une durée de temps
(le plus souvent 15 jours) pendant laquelle
l’équipe scrum définit des choses à faire qu’elle s’engage à terminer et qui doivent respecter
la Définition Of Ready (DoR) 
établie par l’équipe pendant la période de cadrage ou sprint 0.
L’équipe s’engage également à atteindre un objectif à chaque sprint. En fin de sprint l’équipe scrum sera capable de livrer un incrément du produit qui pourra être présenté aux parties prenantes (Clients, utilisateurs.)

Phase 0 : Cadrage

Avant le premier sprint de developpement  l’équipe scrum organise un sprint zéro qui aura pour but de définir la manière dont le travail sera réalisé lors du premier sprint, d’écrire la DoR et la DoD, de se mettre d’accord sur les dates et heures des rituels, de s’accorder sur le workflow, les types de tickets que l’équipe souhaite utiliser et de revoir tous les points qui vont permettre à l’équipe de bien se mettre d’accord sur sa manière de travailler.

Tout au long de la vie du produit, chaque fois que cela sera nécessaire, l’équipe pourra décider d’améliorer certains processus mis en place pendant cette phase.

Phase 1 : Préparation

Tout commence par un besoin

Le PO va receuillir le besoin de son client. Une amélioration, une nouvelle fonctionnalité, tout ce qui va pouvoir améliorer et faire avancer le produit sera identifié et priorisé par le PO dans son product backlog.

Le Scrum master travaille avec lui dans cette permière phase, il est capable de proposer au PO des ateliers, des outils pour l’aider à prioriser et affiner ses différentes tâches. C’est le moment ou le PO va écrire ses histoires utilisateurs (User stories) qui vont décrire le besoin de  son client. Il doit respecter une nomemclature bien précise pour écrire ses US afin que leur description répondent à : Qui demande, qu’est ce qui est demandé et pourquoi c’est demandé. Cela permet à l’équipe d’avoir une bonne vision du travail à faire.

Il pourra faire appel à l’équipe de réalisation pour l’aider à bien découper ses différentes tâches. On organise des ateliers de backlog refinement pour premettre cette phase d’affinage. Pendant ces ateliers, l’équipe est réunie pendant 45 minutes max, le PO présente ses US, les developpeurs posent des questions, ils peuvent proposer un découpage plus judicieux, on peut aussi estimer les tâches qui sont déjà prêtes pour anticiper le premier rituel scrum qui est souvent long et fastidieux.

Phase 2 : début

C’est le sprint planning, rituel de début du sprint pendant lequel le PO va présenter les tâches qu’il aura priorisées en fonction de la valeur qu’elles vont apporter aux utilisateurs à la fin du sprint.

Le PO indique un objectif de sprint en rapport avec cette valeur.

Il donne de la vision à l’équipe.

L’équipe de réalisation estime chaque chose à faire (User story, Bug, étude etc ..) avec des points de compléxité ou d’éffort (Story point). On utilise souvent la suite de Fibonnaci pour estimer les tâches.

Le sprint démarre lorsque le nombre de points associés aux tâches correspond à la vélocité de l’équipe. (moyenne des points réalisés sur les 3 derniers sprint et moyenne de présence de l’équipe de réalisation). 

La liste des tâches et l’objectif de sprint constitue le sprint backlog que l’équipe s’engage à terminer à la fin du sprint.

C’est l’équipe de réaliation qui est entièrement responsable de sa manière de prioriser les différentes tâches du sprint backlog.

Phase 3 : Pendant le sprint

L’équipe déroule un rituel quotidien à la même heure, pendant 15 minutes :  le Daily meeting pendant lequel chaque membre de l’équipe raconte :

Ce qu’il a fait hier
Ce qu’il fera aujourd’hui
Les obstacles qui empêcheront d’atteindre l’objectif du sprint.

Le PO n’est pas forcement convié à ce rituel. Il ne doit pas mener cet atelier. C’est le scrum master qui prendra le rôle du faciliateur quand l’équipe n’est pas encore assez mature pour le faire elle-même.

L’équipe de réalisation developpe, teste, déploie tout le code qui constuit les nouvelles tâches demandées : nouvelles fonctionnalités ou amélioration d’existantes.

les changements qui pourraient compromettre l’objectif du sprint sont évités et l’équipe ne doit pas ajouter nouvelles tâches pendant toute la durée de son sprint sauf si en cas de force majeur et dans ce cas une autre tâche de même valeur devra être dépriorisée.

Phase 3 : Fin du sprint

Chaque sprint se termine par un sprint review (revue de sprint) rituel qui permet d’inspecter l’incrément de produit et adapter le backlog de produit, si nécessaire. La revue de sprint est une collaboration entre l’équipe scrum  et les parties prenantes, qui discutent de ce qui a été réalisé et des prochaines choses qui pourraient être faites pour augmenter la valeur du produit.

Une rétrospective du sprint est également organisée à la fin du sprint, au cours de laquelle l’équipe scrum s’inspecte elle-même et identifie un plan pour apporter des améliorations au cours du prochain sprint.

A chaque fin de sprint, l’équipe est capable de livrer un incrément du produit, un  morceau de produit qui sera terminé et pourra être présenté aux parties prenantes (Clients, Utilisateurs). Elle avance ainsi, de manière incrémentale pour qu’à chaque modification, amélioration, nouvelle fonctionnalité livrée,  la pertinence du résultat puisse être évaluée afin de décider de l’évolution suivante et d’adapter les prochaines livraisons.

a propos

Coach Agile  j’accompagne les organisations et les équipes à comprendre et à mettre en place les principes de l’Agilité (mindset, framework, méthodes, outils)
En savoir plus