Le terme Scrum est emprunté au rugby à XV et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée.
Le principe de base de Scrum est de focaliser l'équipe de façon itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de réduire au maximum les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe.
Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en cours de réalisation pendant un sprint.
Scrum utilise une planification à trois niveaux : release/projet, sprint et quotidien.
Scrum est un processus itératif : les itérations sont appelées des sprints et durent en théorie 30 jours calendaires. En pratique, les itérations durent généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste d'items de backlog de produit (fonctionnalités) à réaliser. Ces items sont décomposés par l'équipe en tâches élémentaires de quelques heures, les items de backlog de sprint.
Pendant un sprint, les items de backlog de sprint à réaliser ne peuvent pas être changés. Les changements éventuels sont pris en compte dans le backlog de produit et seront éventuellement réalisés dans les sprints suivants.
Il y a une exception à cela : il se peut que l'équipe se rende compte en cours du sprint qu'elle n'aura pas le temps de terminer un item du backlog de sprint ou au contraire qu'elle aura fini en avance. Dans ce cas, et seulement d'un commun accord entre l'équipe et le directeur du produit, on peut enlever ou ajouter un item à ce qui a été prévu.
Pour améliorer la lisibilité du projet, on regroupe généralement des itérations en releases. Bien que ce concept ne fasse pas explicitement partie de Scrum, il est utilisé pour mieux identifier les versions. En effet, comme chaque sprint doit aboutir à la livraison d'un produit partiel, une release permet de marquer la livraison d'une version aboutie, susceptible d'être mise en exploitation.
Il est intéressant de planifier à l'échelle d'une release, en répartissant les items du backlog de produit sur les sprints, en respectant leur priorité. Bien entendu, ce qui est planifié au-delà du sprint courant peut changer à tout moment, rien n'est figé à l'avance.
Au quotidien, une réunion, le ScrumMeeting, permet à l'équipe et au ScrumMaster de faire un point d'avancement sur les tâches et sur les difficultés rencontrées.
Scrum définit trois rôles principaux : le directeur de produit, le facilitateur / animateur et l'équipe. Des intervenants peuvent s'intégrer également au projet de façon plus ponctuelle.
Le directeur de produit (Product Owner) est le représentant des clients et utilisateurs. C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées et qui prend les décisions importantes concernant l'orientation du projet. Le terme directeur n'est d'ailleurs pas à prendre au sens hiérarchique du terme, mais dans le sens de l'orientation.
Dans l'idéal, le directeur de produit travaille dans la même pièce que l'équipe. Il est important qu'il reste très disponible pour répondre aux questions de l'équipe et pour lui donner son avis sur divers aspects du logiciel (interface par exemple).
L'équipe ne comporte pas de rôles prédéfinis, elle est auto-gérée. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble et personne ne donne d'ordre à l'équipe sur sa façon de procéder. Contrairement à ce que l'on pourrait croire, les équipes auto-gérées sont celles qui sont les plus efficaces et qui produisent le meilleur niveau de qualité de façon spontanée.
L'équipe s'adresse directement au directeur de produit. Il est conseillé qu'elle lui montre le plus souvent possible le logiciel développé pour qu'il puisse ajuster les détails d'ergonomie et d'interface par exemple.
Le facilitateur / animateur (ScrumMaster) joue un rôle capital : c'est lui qui est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non techniques (administratifs par exemple). Il doit aussi veiller à ce que les valeurs de Scrum soient appliquées, mais il n'est pas un chef de projet ni un intermédiaire de communication avec les clients.
On parle parfois d'équipe étendue, qui intègre en plus le ScrumMaster et le directeur de produit. Ce concept renforce l'idée que client et fournisseur travaillent d'un commun effort vers le succès du projet.
Les intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans réellement s'investir dedans. Il peut s'agir par exemple d'experts techniques ou d'agents de direction qui souhaitent avoir une vue très éloignée de l'avancement du projet.