Un processus de travail organisé selon le principe de Scrum fait intervenir des événements récurrents. Puisque Scrum est un processus itératif, le travail est accompli dans des cycles répétitifs : chaque événement est répété à chaque nouveau cycle. Grâce à la fréquence de ces événements, les réunions imprévues ne sont que rarement ou absolument pas nécessaires. Tous les événements sont par ailleurs limités dans le temps.
On appelle ce cycle un Sprint. Il décrit la période d’une phase de développement. À la fin d’un Sprint, l’équipe de développement livre un incrément produit fini. Cela signifie que le développement doit avoir donné naissance à un produit potentiellement livrable. Chaque Sprint a ainsi une mission concrète que l’on marque comme « terminée » à la fin du cycle. La limite temporelle d’un Sprint est définie au préalable, mais ne devrait pas dépasser 30 jours. Pour déterminer cette limite, il doit être tenu compte des facteurs suivants : un Sprint ne peut être ni prolongé ni raccourci et les futurs Sprints du projet devront avoir la même longueur.
Les Sprints sont délibérément courts afin de formuler les objectifs de façon aussi simple que possible. Cette courte durée permet également d’assurer une vérification du développement au minimum une fois par mois. Dans des cas exceptionnels, le Product Owner (et uniquement lui) peut annuler un Sprint. Une telle annulation est par exemple possible lorsqu’il n’est plus nécessaire d’atteindre l’objectif, car l’entreprise a fixé un nouvel objectif entre-temps. En principe, les Sprints ne doivent pas être annulés, car cette annulation diminue fortement la productivité.
Un Sprint commence avec la Planification du Sprint (Sprint Planning) : tous les rôles de l’équipe Scrum participent à cet événement. Les parties prenantes discutent d’un incrément produit en attente pendant une réunion d’une durée maximale de huit heures : ils déterminent ce que doit contenir cet incrément et comment ils souhaitent atteindre ce résultat. Le Backlog Produit sert de point de départ à la planification. L’équipe de développeurs et le Product Owner s’entendent sur les objectifs pouvant être atteints au cours du mois à venir. L’équipe de développeurs discute ensuite de la façon dont les tâches doivent être réalisées. À la fin de la réunion, les développeurs doivent pouvoir s’entretenir de leur plan avec le Product Owner et le Scrum Master.
Une Mêlée quotidienne (Daily Scrum) doit avoir lieu chaque jour d’un Sprint – toujours au même moment et au même endroit afin d’économiser sur les frais d’organisation. Dans le cadre de cette réunion de 15 minutes, l’équipe de développeurs fait le tour des tâches à réaliser dans la journée et de ce qui a été effectué la veille. Les développeurs évaluent également l’avancée globale du projet : Où en est-on dans le traitement des entrées du Backlog ? Ce recoupement quotidien permet de garantir que toutes les parties prenantes gardent un œil sur l’objectif ce qui, à terme, augmente également la productivité.
Le Scrum Master veille à la tenue de cette mêlée quotidienne, mais son contenu est décidé par les développeurs. Ils déterminent quels seront les thèmes abordés. Le Scrum Master n’intervient pas tant que le contenu de cette réunion porte sur l’accomplissement de l’objectif du Sprint et qu’elle ne dépasse pas 15 minutes. Il veille également à ce que les autres personnes assistant à la mêlée quotidienne ne perturbent pas les développeurs dans leur travail.
Une revue deSprint (Sprint Review) est effectuée à la fin de chaque Sprint : elle consiste à vérifier l’incrément produit. Les résultats sont analysés conjointement avec des personnes ne faisant pas partie de l’équipe Scrum, mais ayant un intérêt considérable au produit, par exemple les propriétaires de l’entreprise ou les clients (regroupés sous le terme Stakeholder dans Scrum). Cette revue aborde le processus de travail en tant que tel, revient sur les problèmes rencontrés lors du développement et comporte un échange sur les défis à relever. Elle a également une influence sur la suite de la planification, car le Product Owner utilise cette opportunité pour aborder les progrès du Backlog. Les conclusions du Sprint impactent les pronostics pour les futures prestations.
La situation correspondante du marché a également une influence sur le Backlog : pour les projets à long terme, en particulier, certaines priorités peuvent être reportées au fil du temps et les budgets peuvent être modifiés. Ces sujets sont également pris en compte dans la revue de Sprint et viendront modifier la stratégie future. En cas de Sprint d’un mois, la revue ne doit pas durer plus de quatre heures.
La revue du Sprint est suivie par un autre examen : la rétrospective de Sprint (Sprint Retrospective). Au cours d’une réunion de trois heures au maximum, l’ensemble de l’équipe Scrum (c’est-à-dire l’équipe de développeurs, le Product Owner et le Scrum Master, mais pas les Stakeholders) se réunit pour apporter un feed-back. Si la revue se concentre principalement sur le produit et l’avancée du projet, la rétrospective s’intéresse majoritairement au travail en équipe. L’objectif de ce second examen est d’améliorer le travail collectif et de résoudre les problèmes internes. Dès qu’un Sprint est achevé, le suivant lui succède en commençant par la phase de planification du Sprint.