Définition

Scrum est une méthode de développement agile orientée projet informatique dont les ressources sont régulièrement actualisées. La méthode Scrum tire son nom du monde du rugby, scrum = mêlée.
Le principe de base étant d'être toujours prêt à réorienter le projet au fil de son avancement.
C'est une approche dynamique et participative de la conduite du projet. La mêlée est une phase de jeu essentielle au rugby.
Elle permet au jeu de repartir sur d'autres bases. La réunion dans la méthode Scrum relaie la métaphore.

Principes de la méthode Scrum

Bien entendu, la méthode Scrum est conforme aux principes des méthodes agiles.
Comme toutes les méthodes agiles, Scrum privilégie la livraison rapide d'un prototype, opérationnel par définition, afin que les clients, donneurs d'ordre et membres de l'équipe puissent l'évaluer.

Cette démarche participative active est un atout fondamental. Elle garantit pour le client le juste équilibre entre l'investissement prévu et le produit finalement livré.
L'étude du prototype permet l'évaluation des fonctionnalités réalisées, et facilite la réflexion commune sur l'opportunité de futurs développements.
D'autre part, l'étroite intimité entre les clients utilisateurs et les prestataires développeurs facilite l'appropriation future de l'outil.

Sprint

• Le Software Development Life Cycle est divisé en plusieurs itérations (ou sprints).
• Le nombre de sprints à venir est indéfini.
• On arrête les sprints uniquement quand on abandonne un produit.
• La durée d'un sprint est fixée globalement à une durée comprise entre 1 et 4 semaines.
• La durée est généralement fixée à 2 semaines et idéalement à 1 semaine.

Sprint Planning

Chaque Sprint démarre avec un Sprint Planning lors duquel l'équipe doit définir :

• what : l'objectif du Sprint ou Spring Goal.
• how : puis comment atteindre cet objectif.

What : Sprint Planning 1 et définition du Sprint Goal La Scrum Team se réunit en entier (Product Owner, Development Team et Scrum Master) pour définir le Sprint Goal.
Le Product Owner décrit les User Stories qu'il souhaiterait assigner au Sprint.
La Development Team peut interroger le Product Owner pour mieux comprendre le besoin.
Si une User Story est de taille importante, il s'agit alors d'une Epic et la Scrum Team peut alors décider de la décomposer en User Stories plus fines.
La Development Team évalue et sélectionne à elle seule les User Stories qu'elle pense être capable de finir d'ici la fin du Sprint.

How : Sprint Planning 2 Suite au Sprint Planning 1, la Scrum Team peut libérer le Product Owner.
La Development Team réfléchit et présente la conception / architecture / design de chaque User Story.
Cela peut se faire avec toute l'équipe ou par paire afin de paralléliser la réflexion si cela est vraiment nécessaire. Dans ce cas, la paire doit présenter le résultat de sa réflexion au reste de l'équipe.
Chaque User Story est ensuite décomposée en tâches techniques.
Les membres de la Development Team doivent ensuite se répartir naturellement ces tâches.

Planning Poker Pour encourager tous les membres de la Development Team à participer à l'estimation de l'effort associé aux User Stories, l'équipe peut utiliser un jeu de cartes grâce auquel chacun réfléchit à son estimation puis tout le monde dévoile sa carte simultanément.

Daily

Le Stand-Up Meeting (ou Daily Scrum) est un point informel qui se tient tous les jours debout et à la même heure (autour d'un café par exemple). En présence du Scrum Master, durant le Stand-Up Meeting chaque membre de l'équipe aborde les points suivants :

• Ce qu'il a fait depuis le dernier Stand-Up Meeting.
• Ce qu'il prévoit de faire en attendant le prochain Stand-Up Meeting.
• Les difficultés rencontrées.

La durée maximum du Daily est de 15 minutes.
Evitez de dépasser la durée maximum (15 minutes)
Les objectifs du Daily est :

• d'encourager la communication dans l'équipe,
• d'éviter l'isolement des développeurs et donc les blocages et la complexité artificielle,
• de déceler rapidement des difficultés potentielles,
• de détecter quand un membre de l'équipe à besoin d'aide,
• de décider de changer de paires dans le cas du Pair Programming,
• de propager la connaissance dans l'équipe,
• de réfléchir rapidement et en groupe à des besoins de conception, d'architecture,
• d'éviter d'avoir à organiser des réunions supplémentaires dans la journée.

Sprint Review

A la fin de chaque Sprint, la Development Team, le Product Owner et le Scrum Master se réunissent.
Le(s) client(s) et les développeurs d'autres équipes peuvent être invités.
Comme les autres évènements d'un Sprint, le Sprint Review doit rester informel (pas de slides etc...).
La durée maximum du Sprint Review est d'1 heure pour une itération d'une semaine.
Cette durée est proportionnelle à celle des itérations.
Objectifs du Sprint Review

• Présentation (par le Product Owner) des User Stories finalisées et celles qui ne le sont pas.
• Présentation (par la Development Team) des difficultés rencontrées et des solutions adoptées.
• Récolte de "feedback" de tout le monde (membres de l'équipe, client, autres équipes etc...).
• Présentation du Backlog et des dates projetées des releases à venir si nécessaire (Cf. vélocité).
• Reflexion et sélection des objectifs futurs.
• Les User Stories non finalisées ne sont jamais présentées pendant le Sprint Review.
• L'une des principales raisons et que certaines personnes extérieures à l'équipe pourraient forcer la livraison ou "vendre" une User Story non finalisée.

Sprint Retrospective

Suite au Sprint Review, l'equipe se réunit avec le Scrum Master.
Le Sprint Retrospective est une réflexion autour du Sprint passé.
Le Sprint retrospective ne doit pas durer plus de 45 minutes pour des itérations d'une semaine.
Cette durée est proportionnelle à celle des itérations.
Le Sprint Retrospective est l'un des évènements les plus importants du Sprint.

Objectifs du Sprint Retrospective
Analyser le déroulement du Sprint passé avec un focus sur :

• les personnes (e.g. : détecter la démotivation et en analyser l'origine),
• les relations (e.g. : détecter les conflits, analyser les paires qui fonctionnent le mieux),
• les process (e.g. : déceler les faiblesses des process actuels ou ceux qui nuisent à la Developer eXperience)
• et les outils (e.g. : est-ce que les outils utilisés sont adaptés et est-ce qu'ils sont utilisés convenablement ?).
• Analyser les indicateurs, identifier et ordonner ce qui s'est bien déroulé et les axes d'amélioration.
• Définir un plan d'amélioration pour réparer ce qui est cassé dans le Scrum.

Backlog Refinement

Le Backlog Refinement (ou Backlog Grooming) regroupe toute la Scrum Team (Development Team, Scrum Master et Product Owner) afin de donner de la visibilité sur les Sprints à venir et le travail restant.
Sans le Backlog Refinement, la décomposition des Epics se fait en début de Sprint durant le Sprint Planning et la visibilité est donc réduite au Sprint actuel.

Objectifs du Backlog Refinement

• Clarifier et décomposer les Epics.
• Evaluer ou réévaluer l'effort nécessaire pour réaliser des User Stories.
• Retirer les User Stories superflues.
• Ajouter de nouvelles User Stories.
• Le Backlog Refinement peut avoir lieu une à deux fois par semaine (et non par Sprint).
• Si la Development Team finalise toutes les User Stories avant la fin du Sprint, le Backlog Refinement permet d'ajouter de nouvelles User Stories au Sprint Goal du Sprint actuel.

Le Backlog Refinement ne doit pas durer plus d'une heure.