Le Sprint

La définition de fini

A la fin d’un sprint, l’équipe obtient un résultat. Mais cela ne suffit pas : il faut qu’il soit “fini” afin que le sprint soit un succès pour tout le monde. Qu’est-ce que cela veut dire ?

• La perception du fini n’est pas la même pour tout le monde.

  Exemple : Bob peut croire que c’est fini quand il a écrit son code et passé ses tests unitaires, mais ce n’est pas tout à fait fini pour Capri la Product Owner, si elle considère que l’usage n’est pas aisé pour un utilisateur final.

Le tempo dans Scrum est donné par le sprint, de durée fixe et courte, dont on ne peut pas repousser l’échéance, et qui aboutit à un résultat. Ce résultat fonctionne et apporte potentiellement de la valeur aux parties prenantes si le contenu et la qualité sont au point.

L’objectif du sprint porte sur le contenu

C’est pour réduire le risque sur le contenu de cet incrément qu’on s’aligne sur un objectif de sprint, communiqué aux parties prenantes. Chaque sprint possède un objectif, défini au début et vérifié à la fin. Il prend la forme d’une phrase résumant le contenu sur lequel l’équipe va se focaliser et s’engager devant les parties prenantes.

• Donner un objectif

  Focalisation et engagement de l’équipe.

La définition du fini porte sur sa qualité

Pour que le sprint soit un succès, son objectif doit être atteint, mais il faut aussi que le niveau de qualité donné par la définition de fini (definition of done – DoD) soit respecté.
Dans une approche traditionnelle, quand on constate des résultats en deçà des attentes, on repousse la date du passage à l’étape suivante.

• Interdit avec le Scrum. Si l’objectif n’est pas atteint

  Report d’une ou plusieurs stories dans le prochain Sprint.

• La définition de fini se porte sur les éléments (stories, fonctionnalités) dès qu’ils se terminent.

Fini pour une story

Ce sont les stories qui sprintent et elles ne finissent pas toutes en même temps.

• La définition de fini porte sur la liste des vérifications rédigées au début du projet.

Si le test d’une condition d’acceptation passe avec succès, la story fonctionne, mais n’est pas finie pour autant. Il est possible qu’elle ait provoqué une régression sur une story qui fonctionnait avant, ou bien qu’elle ne soit pas facile à utiliser (mauvaise ergonomie) ou bien encore qu’elle ne soit pas maintenable. C’est pour éviter cela que la définition de fini existe.

• Bug qui peut donner naissance à une story

Catégories de vérification

Pour que la story soit vraiment finie, il convient d’effectuer des vérifications autres que le test du fonctionnement. On peut les classer en trois catégories :

• Celles qui portent sur le test des conditions d’acceptation (qui, quand, sur quel environnement)

  Fonctionnement.

• Celles qui portent sur des aspects visibles par les parties prenantes (utilisabilité, fiabilité, performance, sécurité, etc.)

  Qualité externe.

• Celles perceptibles uniquement par l’équipe (maintenabilité, réutilisabilité, etc.)

  Qualité interne.

Planifier le sprint

La planification du sprint n’est pas vraiment une séance de planification dans le sens premier. Le résultat n’est pas un plan détaillé, qui dit qui travaille sur quoi pour toute la durée du sprint.

• Il s’agit plutôt de réapprovisionner l’équipe, en ce début du sprint, pour qu’elle ait du grain à moudre. Pas n’importe quel grain, celui qui la guide vers l’objectif.
• C’est aussi un rituel qui prépare l’équipe à travailler de façon collective pendant le sprint.

Quoi ? C’est la story qui sprinte

• Une story est prête si elle est suffisamment petite et bien comprise par l’équipe, qui se sent alors capable de la finir dans un sprint.
• Pendant le sprint, les stories seront traitées en flux continu : dès que possible, une va démarrer puis continuer sa course jusqu’à ce qu’elle soit finie.

Qui ? C’est l’équipe qui planifie

Plus que le résultat, c’est la planification collective qui est importante : les réflexions faites au cours de ce rituel soudent l’équipe.

• Ce travail inclut le Product Owner.

  Il doit répondre aux questions de l’équipe et doit s’assurer de la compréhension et de l’engagement.

• Les parties prenantes peuvent être amenées parfois à intervenir.

Quand ? C’est le premier événement du sprint

Cet événement est le tout premier du sprint qui commence. Il est limité dans le temps, comme tous les événements du sprint.

L’équipe a un objectif

Le résultat essentiel est la focalisation de l’équipe vers son objectif de sprint. Dans l’idéal, cet objectif portera sur une fonctionnalité déjà connue des parties prenantes et visible dans le backlog de fourniture.

Le plan de sprint

Pendant le sprint, une story passe par trois des états présentés dans le pattern des bacs : prête, en course (c’est un sprint) et finie.

• La planification fait passer des stories de prête à en course.

Pour ces stories en course, il est possible d’en dire plus, avec le détail des travaux. On appelle tâches les morceaux constituant le travail à faire pour une story. Les tâches sont présentées sur trois colonnes (à faire, en cours, fini).

L’ensemble constitue le plan du sprint.

Comment planifier le sprint

• L’équipe se met dans le contexte du sprint.
• Elle s’assure, avec le PO, d’avoir un backlog prêt pour le sprint.
• Eventuellement elle procède à l’identification des tâches.
• Avec cette connaissance du travail à faire, l’équipe s’engage sur l’objectif du sprint.
• Le sprint est alors lancé.