Nous créons le succès numérique
Elasticbrains
Schieggstr. 23D
81479 Munich
+49 176 8562958
© 2023 Elasticbrains |
Mentions légales
|
Protection des données
Menu
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
- s’il y a des sujets à clarifier
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
Plus de sujets dans notre section Agile :
Nous nous réjouissons de votre demande
