Rôles, artefacts et événements

Rôles, artefacts et événements selon le Guide 2020

1. Les trois responsabilités, et le vocabulaire exact

   Scrum définit trois responsabilités au sein de l'équipe, et une seule personne peut encumuler deux. Ce ne sont pas des postes hiérarchiques.

   Les trois responsabilités

   • Developers — les personnes qui réalisent l'incrément. Elles décident comment faire le travail, et personne d'autre ne peut leur dire comment. Ni le Product Owner, ni le manager, ni le client ;
   • Product Owner — responsable de la maximisation de la valeur du produit. Il ordonne le Product Backlog et décide de ce qui est fait. Il n'a pas à être le client, ni le chef de projet, ni le responsable des communications ;
   • Scrum Master — responsable de la compréhension et de l'application de Scrum. Son travail est de lever les obstacles, pas de distribuer les tâches ni de.jetbrains la productive.

   Un point de vocabulaire qui n'est pas cosmétique

   La version 2020 du Guide a remplacé « Development Team » par « Developers », et a retiré la notion de membre externe de l'équipe : l'équipe L'équipe Scrum compte au plus dix personnes, toutes impliquées sur le produit entier. L'objectif était de retirer l'image de l'équipe de développement comme groupe d'experts distinct du reste, et de mathvariant la responsabilité de chacun sur le produit entier.

   Un cours ou un consultant qui parle encore de « Development Team » et de « l'équipe de développement » en 2026 utilise un vocabulaire périmé de dix ans. Ce n'est pas grave en soi, mais cela signale que la formation s'est arrêtée à une version antérieure — et c'est exactement le type de décalage que ce cours cherche à éviter.

   Pourquoi la taille est limitée

   L'équipe Scrum est bornée à dix personnes ou moins. Au-delà, la coordination consume la capacité : le nombre de relations dans une equipe double en fonction quadratique. Passer de dix à quatorze personnes ne multiply donc pas la production par 1,4 : la coordination mangera une partie du gain, et l'agilité disparaît. La réponse n'est pas d'agrandir l'équipe mais de la découper en plusieurs équipes, ce qui a un coût d'architecture à assumer explicitement.

2. Trois artefacts, trois engagements

   La version 2020 a clarifié un point resté flou jusque-là : chacun des trois artefacts porte un engagement. Cet engagement est ce qui rend l'artefact transparent.

   Artefact	Engagement
   Product Backlog	Product Goal
   Sprint Backlog	Sprint Goal
   Increment	Definition of Done

   La Definition of Done n'est pas négociable

   La définition de « terminé » décrit l'état d'un incrément qui respecte les exigences de qualité du produit. Sa règle la plus importante, et la plus souvent violée :

   Un élément du Product Backlog qui ne respecte pas la Definition of Done ne peut être ni mis en production, ni même présenté à la revue de sprint. Il retourne au Product Backlog.

   Cette règle protège la rétrovision. Une revue de sprint où l'on présente du travail non terminé apprend à l'équipe et aux parties prenantes à ne plus croire aux revues. Si c'est un standard de l'organisation, toutes les équipes doivent le respecter au minimum.

   Le Sprint Goal : le recentrage du cycle

   Le Sprint Goal est un objectif unique, formulé en un objectif, qui donne de la cohérence à des travaux qui n'auraient pas de sens ensemble. C'est ce qui évite que le sprint devienne une course à la quantité d'histoires terminées.

   Product Backlog : ordonné, pas figé

   Le Product Backlog n'est pas une liste gelée : il est ordonné par valeur, et l'ordre évolue au fil de ce que l'équipe apprend. Le mot « affinage » a remplacé « grooming » dans le Guide 2020 — ce n'est pas un simple changement de mot, l'affinage désigne le travail de rendre un élément assez clair, assez découpé et assez petit pour être planifiable.

3. Les événements et leur durée maximale

   Le Guide fixe une durée maximale à chaque événement, dans un but précis : réduire le besoin de réunions informelles. Un événement qui dépasse sa durée ne devient pas plus utile, il consomme du temps qui aurait servi au travail.

   Le Sprint : un mois ou moins

   Un conteneur d'un mois au maximum, de durée constante : elle ne se raccourcit pas et ne se prolonge pas. Un sprint de six semaines, c'est quatre sprints, pas un sprint long. La durée maximale d'un mois est un choix cohérent avec la définition même de Scrum : si le cycle doit être plus long, le problème est dans la granularité des éléments, pas dans le format.

   Les quatre événements

   1. Planification de sprint : l'équipe répond à deux questions — que peut-elle livrer, et comment ? Puis elle formule le Sprint Goal. Un seul événement, et non deux comme dans les versions antérieures ;
   2. Mêlée quotidienne : 15 minutes, chaque jour, au même endroit, pour planifier les 24 prochaines heures. Ce n'est pas un rapport de statut — c'est le principal malentendu ;
   3. Revue de sprint : démonstration du travail fini et collecte des retours sur ce qui sera ensuite demandé. L'objectif est adapter le Product Backlog ;
   4. Rétrospective : improving façon dont l'équipe travaille, sur trois éléments : ce qui a marché, ce qui a posé problème, ce qu'on essaie au prochain cycle.

   Le Daily reformulé en 2020

   La version 2020 a recentré les trois questions sur l'équipe et l'objectif, et non sur l'individu :

   1. qu'ai-je fait hier qui a aidé l'équipe à atteindre le Sprint Goal ?
   2. que vais-je faire aujourd'hui pour que l'équipe atteigne le Sprint Goal ?
   3. vois-je un obstacle qui empêche l'équipe d'atteindre le Sprint Goal ?

   La nuance n'est pas rhétorique : la première question fait passer le propos du « j'ai fini ma tâche » au « j'ai contribué à l'objectif de l'équipe ». C'est le moyen le plus simple de faire disparaître le rapport de statut.