Rituels et artefacts Scrum

Les 3 artefacts Scrum utilisés dans Scrum sont le Product Backlog, le Sprint Backlog et le Product Increment.

Les 5 rituels (événements) sont le sprint, le sprint planning, le daily scrum, la revue et la rétrospective.

Événements (rituels)

Artefacts

Artefacts Scrum

Backlog de produit

Contient si possible toutes les fonctionnalités planifiées sous forme de User Stories, qui sont priorisées les unes par rapport aux autres au sein du backlog.
Est géré par le Product Owner

Backlog de sprint

Les user stories pertinentes pour le sprint en cours
La portée du backlog de sprint est fixe au sein du sprint (engagement des développeurs).

Incrément

Le logiciel / l’application à mettre en œuvre dans chaque sprint
Toujours exécutable dans le cadre de la spécification de la User Story

Rituels Scrum

OBJECTIF :
Planification du prochain sprint

Planification de sprint

Le Sprint Planning se compose de deux parties, le Planning 1 et le Planning 2.
Dans la première partie du Sprint Planning, les User Stories planifiées et priorisées par le Product Owner (PO) sont présentées à l’équipe de développeurs. Les développeurs apprécient les User Stories et donnent un premier engagement.
Dans la deuxième partie de la planification, les développeurs planifient grossièrement le sprint, créent des sous-tâches, identifient les risques et donnent un engagement final.

Participants

Product Owner:in
Équipe interfonctionnelle
Scrum Master:in

OBJECTIF :
Transparence sur l’état actuel du sprint, communication au sein de l’équipe et identification rapide des bloqueurs

Daily (standup)

Le Daily est généralement limité à 15 min.
Chaque participant(e) répond à trois questions :
- Qu’est-ce que j’ai fait (hier) ?
- Qu’est-ce que je fais aujourd’hui ?
- Qu’est-ce qui me bloque en ce moment ?
Important pas de discussion –> Timebox à 15 minutes
- s’il y a des sujets à clarifier
  –> réunion dédiée, ou directement après le Daily

Participants

Product Owner:in
Équipe interfonctionnelle
Scrum Master:in

OBJECTIF :
Amélioration continuedu processus et/ou élimination des problèmes

Rétrospective

Le Scrum Master prépare des formats alternés afin de recueillir en permanence les expériences positives et négatives des participants au projet et les propositions d’amélioration.
Exemples :
- Démarrer / arrêter / continuer
- Mad / Sad / Glad
- Équipe / Projet SWOT
- Lean Coffee
Des tâches concrètes doivent toujours en ressortir, qui peuvent être mises en œuvre dans le sprint suivant afin d’améliorer continuellement le processus.

Participants

Product Owner:in
Équipe interfonctionnelle
Scrum Master:in

Autres outils pour les rétros :

OBJECTIF :
Présenter l’artefact mis en œuvre lors du dernier sprint qui vient de se terminer.

Revue de sprint (démo)

Présentation par les développeurs des fonctionnalités mises en œuvre
Présentation des KPIs atteints pendant le sprint (Stories ouvertes, Stories fermées, Velocity, etc)
Si les parties prenantes sont présentes, le cadre pourrait également être utilisé pour communiquer un état général du processus global.

Participants

Product Owner:in
Équipe interfonctionnelle
Scrum Master:in
Le cas échéant Parties prenantes

OBJECTIF :
Présentation de nouvelles stories par le Product Owner (PO) – Estimation des stories par l’équipe pour la planification anticipée des futurs sprints

Refinement

le cas échéant Clarifier les questions relatives aux histoires actuelles
Présentation des nouvelles User Stories par le/la Product Owner
Feedback sur les User Stories par l’équipe
Allègement de la réunion de planification, car les User Stories terminées peuvent déjà être estimées
Priorisation du backlog
“Nettoyage” du backlog

Participants

Product Owner:in
Équipe interfonctionnelle
Scrum Master:in

Définition de prêt / Définition de fait

Exigences formelles, définissables et implicites pour les user stories(DoR) et pour l’incrément(DoD)

Définition de prêt

La User Story est définie dans le backlog.
La User Story répond aux exigences formelles
La User Story a des critères d’acceptation complets
La User Story a défini les premiers cas de test
La User Story répond aux critères INVEST
La User Story a été appréciée par l’équipe de développement
Les dépendances avec d’autres équipes / prestataires de services au sein de la User Story sont identifiées
Toutes les dépendances de tiers, telles que les mises en page, les actifs, les documentations API, les SDK, sont disponibles pour l’équipe.
Les exigences UX ont été intégrées dans la User Story (par ex. comportement dans les Edge Cases)

Définition du fait accompli

la branche develop est “rebased” dans la branche feature et les conflits ont été résolus le cas échéant
l’incrément répond entièrement aux critères d’acceptation
une documentation est créée et des conseils pour tester l’histoire sont disponibles dans les commentaires
L’incrément a été créé sans erreur dans la CI
Le développeur a testé l’incrément créé

Exemple de réunions Scrum

Kanban comme étape préalable à la création d'une histoire

Liens complémentaires :

Conseils d’Elasticbrain sur l’utilisation de Scrum et des processus de développement agile dans le développement de produits numériques

Plus de sujets dans notre section Agile :

Cookie	Durée	Description
cookielawinfo-checkbox-analytics		Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour enregistrer le consentement de l'utilisateur pour les cookies dans la catégorie "Analytics".
cookielawinfo-checkbox-functional		Le cookie est défini par le consentement au cookie GDPR pour enregistrer le consentement de l'utilisateur pour les cookies de la catégorie "Fonctionnel".
cookielawinfo-checkbox-necessary		Ce cookie est défini par le plugin GDPR Cookie Consent. Les cookies sont utilisés pour stocker le consentement de l'utilisateur pour les cookies dans la catégorie "Nécessaire".
cookielawinfo-checkbox-others		Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour enregistrer le consentement de l'utilisateur pour les cookies dans la catégorie "Autres.
cookielawinfo-checkbox-performance		Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour enregistrer le consentement de l'utilisateur pour les cookies dans la catégorie "Performance".
viewed_cookie_policy		Le cookie est défini par le plugin GDPR Cookie Consent et est utilisé pour enregistrer si l'utilisateur a consenti ou non à l'utilisation de cookies. Il ne stocke pas de données personnelles.