Plusieurs événements plus petits constituent un Sprint dans Scrum. Les Sprints, à leur tour, forment ensemble un chemin visant à développer et à publier un Produit. Chaque Sprint a un objectif spécifique de Sprint et un Backlog de Sprint maintenu par l’équipe de développement.

Qu’est-ce qu’un Sprint dans Scrum – table des matières :

  1. Sprint dans Scrum – Introduction
  2. Structure du Sprint dans Scrum
  3. Sprints et les trois piliers de l’empirisme
  4. Transparence
  5. Inspection
  6. Adaptation
  7. Quelles modifications apporter pendant un Sprint ?
  8. Sprint dans Scrum – Résumé

Qu’est-ce qu’un Sprint dans Scrum ?

Le Sprint est le plus grand des événements dans Scrum, dont nous avons parlé dans cet article. Les Sprints suivent un cycle continu du début à la fin du travail sur un Produit. Et chaque itération rapproche l’équipe de l’atteinte de l’objectif du Produit.

Chaque Sprint a un objectif spécifique de Sprint pour garantir la cohérence dans le travail de l’équipe de développement. Il prend la forme d’un objectif commercial et répond à la question “Pourquoi ?”, “Dans quel but ?” ou “Pourquoi ?”.

Le flux de travail d’un Sprint est documenté dans le Backlog de Sprint, qui liste le travail nécessaire pour atteindre l’objectif du Sprint. Sa description détaillée peut être trouvée ici.

sprint in scrum

Structure du Sprint dans Scrum

Chaque Sprint a une structure spécifique et comprend les événements suivants :

  • Planification du Sprint – le Sprint commence. Pendant cet événement, l’équipe Scrum sélectionne le travail prévu dans le Backlog de Produit à réaliser dans le nouveau Sprint
  • Scrum quotidien – un événement quotidien où les développeurs planifient les tâches de la journée
  • Revue de Sprint – ouverte aux parties prenantes, tenue le dernier jour d’un Sprint. Son objectif est de résumer le Sprint en termes de progrès sur le Produit
  • Rétrospective de Sprint – l’événement de clôture d’un Sprint, où l’équipe Scrum discute des méthodes de travail et des idées d’amélioration

La répétition des événements de Sprint favorise la mise en œuvre de bonnes pratiques organisationnelles. En d’autres termes, l’équipe Scrum met en œuvre les routines nécessaires pour une planification efficace et, tout en travaillant, attire l’attention sur les problèmes qui peuvent être discutés lors d’événements appropriés.

Sprints et les trois piliers de l’empirisme

Les Sprints permettent à l’équipe Scrum de décomposer le travail sur le Produit en segments de temps égaux ne dépassant pas un mois. Ce cadre fixe renforce les trois piliers de l’empirisme :

  • transparence
  • inspection
  • adaptation

Nous avons écrit sur les trois piliers de l’empirisme et leur rôle dans Scrum plus en détail ici. Mais aujourd’hui, nous allons examiner comment ils s’appliquent au Sprint et à sa structure.

Qu'est-ce qu'un Sprint dans Scrum

Transparence

Diviser le travail en Sprints améliore la transparence car toutes les personnes impliquées peuvent obtenir les informations requises sur l’état du travail du Produit dans chaque Sprint. La Planification du Sprint et la Revue de Sprint, le début et la fin d’un Sprint, combinées à une mise à jour du Backlog de Produit, fournissent à toutes les parties prenantes des informations précieuses sur l’état actuel du Produit.

Inspection

En divisant le travail en Sprints, il est possible de surveiller fréquemment ses progrès. Cela favorise l’identification constante des problèmes dans deux domaines clés. Ce sont :

  • les problèmes liés à l’atteinte de l’objectif du Produit – au début et à la fin du Sprint, c’est-à-dire lors de la Planification du Sprint et de la Revue de Sprint
  • les obstacles à la manière dont l’équipe Scrum travaille – lors des réunions quotidiennes et à la fin de chaque Sprint, c’est-à-dire lors du Scrum quotidien et de la Rétrospective de Sprint

Adaptation

L’adaptation est une partie très importante du travail de l’équipe Scrum, car elle permet de résoudre les problèmes identifiés lors de l’inspection. Pendant chaque Sprint, le Scrum quotidien et la Rétrospective de Sprint offrent un espace sûr pour parler de la manière d’améliorer l’équipe Scrum. La mise en œuvre des solutions proposées se fait immédiatement ou au début du prochain Sprint.

La Planification du Sprint et la Revue de Sprint créent un espace sûr pour la discussion concernant les objectifs et les méthodes pour les atteindre. Une bonne équipe Scrum autogérée parvient à déterminer ce qu’il faut mettre en œuvre et comment pour le prochain Sprint.

Quelles modifications apporter pendant un Sprint ?

Chaque Sprint laisse suffisamment d’espace à l’équipe Scrum pour améliorer et improviser sa manière de travailler. Par conséquent, identifiez ce qu’il faut changer pendant un Sprint. Le Guide Scrum ne fournit pas de liste de tels changements. Cependant, la notion d’empirisme fournit des lignes directrices à suivre et à adapter à la manière dont une équipe Scrum particulière travaille.

  1. Tous les changements peuvent compromettre l’atteinte de l’objectif du Sprint. Selon la première règle, pendant un Sprint, vous ne pouvez pas, par exemple, réduire le nombre de tâches à faire dans ce Sprint, ou modifier considérablement leurs caractéristiques. Un Sprint est étroitement lié à l’objectif du Sprint. Par conséquent, lorsque l’objectif change, nous devrions interrompre le Sprint. Cependant, cela arrive rarement car la seule raison pour laquelle un Sprint échoue est lorsque l’objectif devient obsolète. Gardez à l’esprit que la décision de mettre fin à un Sprint appartient uniquement au Product Owner.
  2. La qualité du travail ne peut pas être compromise. Cette règle vise à empêcher le travail effectué pendant un Sprint de devenir un Incrément car il ne répond pas à la Définition de Terminé. Réduire la qualité du travail peut entraîner le fait que l’objectif du Sprint soit apparemment atteint, mais la manière dont les tâches individuelles sont réalisées ne respecte pas les normes de qualité établies par l’organisation ou requises par les parties prenantes.
  3. Le Backlog de Produit peut devenir détaillé. En travaillant sur un Produit, les connaissances à son sujet augmentent. Par conséquent, le détail des tâches à réaliser augmente naturellement. Il est donc acceptable et même conseillé de détailler le Backlog de Produit pendant un Sprint.
  4. Le périmètre de travail peut être clarifié ou renégocié. Ce changement, comme le précédent, implique une compréhension croissante de la nature du travail effectué. L’équipe de développement peut le faire en consultation avec le Product Owner. Cependant, la condition de base pour son introduction est l’absence de conflit avec les principes 1 et 2.

Sprint dans Scrum – Résumé

Le Sprint est l’événement cyclique de Scrum qui contient tous les autres. Il a un objectif de Sprint distinct de l’objectif du Produit. Et le Backlog de Sprint est différent du Backlog de Produit. La nature des Sprints est cyclique. La durée fixe des Sprints favorise le maintien de bonnes pratiques de flux de travail et nourrit les trois piliers de l’empirisme. Pendant un Sprint, l’équipe Scrum ne peut pas changer son objectif. Elle peut cependant affiner le Backlog de Produit et, à mesure que les connaissances augmentent, affiner et renégocier le périmètre de travail.

Si vous aimez notre contenu, rejoignez notre communauté de abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Natalia Jaros

View all posts →

Scrum Guide:

  1. Glossaire des termes, rôles et notions de base
  2. Qu'est-ce que Scrum ?
  3. Valeurs Scrum
  4. Comment mettre en œuvre Scrum dans votre entreprise ?
  5. Équipe Scrum - qu'est-ce que c'est et comment ça fonctionne ?
  6. Qui est un Product Owner ?
  7. Les erreurs les plus courantes du Product Owner
  8. Qui est le Scrum Master ?
  9. Les erreurs les plus courantes des Scrum Masters
  10. Quelles statistiques et métriques le Scrum Master devrait-il suivre ?
  11. Équipe de développement en Scrum
  12. Les erreurs les plus courantes des développeurs
  13. Artifacts Scrum
  14. Élargir Scrum
  15. Backlog de sprint
  16. Qu'est-ce que le Product Backlog ?
  17. Qu'est-ce que les User Stories ?
  18. Créer la meilleure User Story avec INVEST
  19. Les erreurs les plus courantes dans les User Stories
  20. Critères d'acceptation de l'histoire utilisateur
  21. Estimation et Points d'Histoire dans Scrum
  22. Planning Poker
  23. Jeu d'estimation d'équipe
  24. Définir l'incrément
  25. Événements Scrum
  26. Qu'est-ce qu'un graphique d'avancement ?
  27. Avantages et inconvénients du graphique de burndown
  28. Tableaux Kanban dans Scrum et Scrumban
  29. Vélocité en Scrum - Vitesse de l'équipe de développement
  30. Scrum quotidien
  31. Planification de Sprint
  32. Revue de Sprint
  33. Qu'est-ce qu'une rétrospective de sprint ?
  34. Erreurs courantes lors d'une rétrospective de Sprint
  35. Nourrir le backlog produit
  36. Comment créer et interpréter un graphique de burndown ?
  37. Qu'est-ce qu'un Sprint dans Scrum ?
  38. Coopération entre le Product Owner et le Scrum Master
  39. Engagements de l'équipe Scrum - Objectif produit, objectif de sprint et définition de la complétion
  40. Caractéristiques d'un bon Scrum Master