Le Scrum Team est l'unité fondamentale de Scrum. Toute la mécanique du framework — événements, artefacts, engagements — n'a de sens qu'au service d'une seule équipe, petite, auto-managée et pluridisciplinaire. Ce guide est conçu pour devenir la meilleure ressource francophone sur le Scrum Team et les questions PSM I qui s'y rapportent.
Qu'est-ce qu'un Scrum Team ?
Le Scrum Guide 2020 définit le Scrum Team comme l'unité fondamentale de Scrum : « une petite équipe de personnes, composée typiquement de 10 personnes ou moins, comprenant un Scrum Master, un Product Owner et des Developers. » Le Scrum Team est cross-functional (toutes les compétences nécessaires sont présentes) et self-managing (auto-managé : il décide en interne qui fait quoi, quand et comment).
Une seule équipe, trois accountabilities, un objectif commun.
Pourquoi Scrum est organisé autour d'une seule équipe
Scrum mise sur la cohésion et la responsabilité collective. Plutôt que d'opposer un « métier » (le PO), un « process » (le SM) et des « techniciens » (les Developers), Scrum les réunit dans une seule unité accountable d'un objectif commun : créer de la valeur produit Sprint après Sprint.
Cette unicité n'est pas symbolique. Elle a des conséquences concrètes : un seul Product Goal, un seul Product Backlog, un seul Sprint Goal, un seul Sprint Backlog, une seule Definition of Done, un seul Increment par Sprint.
Les trois accountabilities
Depuis le Scrum Guide 2020, on parle d'accountabilities et non plus de « rôles ». Une accountability est une zone de responsabilité finale dont quelqu'un répond — sans pour autant être le seul à y contribuer.
| Accountability | Responsabilité finale | Artefact / engagement associé |
|---|---|---|
| Product Owner | Maximiser la valeur du produit. | Product Backlog + Product Goal. |
| Scrum Master | Établir et maintenir l'efficacité de Scrum. | Pratique de Scrum (events, artefacts, valeurs). |
| Developers | Créer un Increment utilisable à chaque Sprint. | Sprint Backlog + Definition of Done. |
Product Owner
Le Product Owner est une seule personne accountable de la valeur produit. Il définit et communique le Product Goal, ordonne le Product Backlog, et s'assure que ce Backlog est transparent, visible et compris. Le PO peut déléguer du travail, mais l'accountability finale lui revient.
Scrum Master
Le Scrum Master est accountable de l'efficacité du Scrum Team et de la mise en pratique de Scrum dans toute l'organisation. C'est un true leader qui sert l'équipe, coache, lève les obstacles, et protège la time-box des événements. Il n'a aucune autorité hiérarchique.
Developers
Les Developers sont les membres du Scrum Team engagés à créer un Increment utilisable chaque Sprint. Le terme « Developer » ne signifie pas « développeur logiciel » : il désigne toute personne qui contribue à produire la valeur — designers, testeurs, data scientists, rédacteurs, ingénieurs, etc.
| Critère | Product Owner | Scrum Master | Developers |
|---|---|---|---|
| Nombre | 1 | 1 | Le reste, idéalement ≤ 8 |
| Focus | Valeur produit | Efficacité Scrum | Increment |
| Artefact | Product Backlog | — | Sprint Backlog |
| Engagement | Product Goal | — | Sprint Goal (avec le PO) + DoD |
| Décide quoi faire | Oui (ordre du Backlog) | Non | Non (sur le scope) |
| Décide comment faire | Non | Non | Oui |
| Autorité hiérarchique | Non | Non | Non |
Pourquoi il n'existe plus de « Development Team » depuis le Scrum Guide 2020
Avant 2020, le Scrum Guide parlait d'une Development Team nichée à l'intérieur du Scrum Team. Cette formulation a créé deux confusions dommageables :
- Une perception d'« équipe dans l'équipe », contraire à l'idée d'unicité.
- Une lecture qui excluait le PO et le SM du « vrai » travail.
Le Scrum Guide 2020 a remplacé « Development Team » par Developers (un rôle interne au Scrum Team), pour souligner qu'il n'existe qu'une seule équipe.
Auto-management
Le Scrum Team est self-managing : il décide en interne qui fait quoi, quand et comment. Cette autonomie n'est pas un droit acquis, elle est une condition d'efficacité empirique — sans elle, l'équipe ne peut ni inspecter, ni adapter.
| Dimension | Management traditionnel | Auto-management Scrum |
|---|---|---|
| Qui fait quoi | Décidé par un chef | Décidé par l'équipe |
| Quand | Planifié par un manager | Planifié par l'équipe |
| Comment | Process imposé | Choisi par l'équipe |
| Reporting | Vers le haut | Vers l'équipe (Daily, Review) |
| Reddition de comptes | Individuelle | Collective (Increment) |
| Décision sur le scope | Chef de projet | PO + Developers (Sprint Planning) |
Cross-functional team
Cross-functional signifie que le Scrum Team possède toutes les compétences nécessaires pour créer de la valeur sans dépendance externe bloquante. Cela ne signifie pas que chaque personne sait tout faire : cela signifie que l'équipe, collectivement, sait tout faire ce qui est requis pour livrer un Increment conforme à la Definition of Done.
| Critère | Équipe spécialisée (silo) | Équipe cross-functional |
|---|---|---|
| Compétences | Concentrées sur une fonction | Couvrent toute la chaîne de valeur |
| Dépendances | Multiples, externes, bloquantes | Minimisées, gérées en interne |
| Vélocité | Saccadée (attentes inter-équipes) | Régulière Sprint après Sprint |
| Increment | Difficile à livrer en un Sprint | Livré à chaque Sprint |
| Apprentissage | Local à la spécialité | Partagé dans toute l'équipe |
Pourquoi il n'existe pas de sous-équipes
Le Scrum Guide 2020 est explicite : il n'y a pas de sous-équipes ni de hiérarchies à l'intérieur du Scrum Team. Créer une « squad front », une « squad back » et une « squad QA » à l'intérieur du même Scrum Team est une violation directe du framework.
Pourquoi ? Parce que les sous-équipes recréent des silos, multiplient les dépendances internes, et fragilisent la responsabilité collective de l'Increment.
Pourquoi il n'existe pas de hiérarchie interne
Ni le Product Owner, ni le Scrum Master, ni un Developer senior n'a d'autorité hiérarchique sur les autres. L'équipe fonctionne à l'influence, pas à l'autorité formelle. Le PO oriente par la valeur, le SM par le coaching, les Developers par leur expertise — mais aucune décision ne s'impose par grade.
Taille recommandée du Scrum Team
Le Scrum Guide 2020 recommande 10 personnes ou moins au total — Product Owner et Scrum Master inclus. Cette borne n'est pas dogmatique : elle reflète des décennies d'observation montrant qu'au-delà, les coûts de communication explosent et l'auto-management devient impossible.
| Taille | Effets typiques | Risque |
|---|---|---|
| ≤ 3 personnes | Manque de compétences, fragilité. | Pas de redondance. |
| 4–7 personnes | Sweet spot : communication fluide, cross-functional viable. | Faible. |
| 8–10 personnes | Encore gérable avec discipline. | Tensions sur le Daily, refinement plus lourd. |
| > 10 personnes | Explosion des canaux de communication. | Auto-management compromis : envisager le scaling. |
Pourquoi une petite équipe est plus efficace
Le nombre de canaux de communication dans une équipe de N personnes est N × (N - 1) / 2. À 5, c'est 10. À 10, c'est 45. À 15, c'est 105. Au-delà d'une dizaine de personnes, l'équipe passe plus de temps à se coordonner qu'à produire.
Une petite équipe est aussi plus apte à partager une compréhension commune du Product Goal, du Sprint Goal et de la Definition of Done — la base de l'empirisme.
Collaboration quotidienne
Au quotidien, le Scrum Team collabore de façon continue : PO et Developers refinent le Backlog, Developers s'entraident pour faire progresser le Sprint Goal, Scrum Master observe et lève les obstacles. Cette collaboration n'a pas besoin d'événements supplémentaires : elle s'incarne dans le travail réel.
Responsabilité collective
Le Scrum Team est collectivement responsable de l'Increment livré. Aucun « sous-Increment » individuel n'est attendu. Si le Sprint Goal n'est pas atteint, c'est l'équipe entière qui inspecte et adapte — pas un individu désigné comme coupable.
La valeur livrée par l'équipe
L'unité de valeur de Scrum est l'Increment. Le Scrum Team existe pour le créer, le livrer et l'améliorer Sprint après Sprint. C'est ce qui le distingue d'un comité ou d'un groupe de projet : il produit, il n'observe pas.
Le Scrum Team est le seul vecteur qui transforme un objectif en valeur livrée.
Relation avec le Product Goal
Le Product Goal est l'objectif à long terme du Scrum Team. Toute l'équipe — PO, SM, Developers — s'oriente vers lui. Le PO en est accountable, mais ce n'est pas son objectif personnel : c'est l'objectif de l'équipe.
Relation avec le Sprint Goal
Le Sprint Goal est défini par le Scrum Team entier pendant le Sprint Planning. Il oriente l'Increment du Sprint. Tous les membres s'engagent collectivement à l'atteindre.
Relation avec la Definition of Done
La Definition of Done (DoD) est partagée par tout le Scrum Team. Elle conditionne la qualité de l'Increment et la transparence du Product Backlog. Les Developers en sont garants au quotidien, mais elle engage l'équipe entière.
Relation avec l'Increment
Chaque Increment doit être utilisable et conforme à la DoD. Il est le produit collectif du Scrum Team. Sans Scrum Team unifié, il n'y a pas d'Increment cohérent.
Relation avec les Scrum Events
Les cinq événements Scrum n'ont de sens qu'au service d'un Scrum Team : Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Chaque événement sert l'inspection ou l'adaptation du travail collectif.
L'équipe entière, et personne d'autre, fait tourner la boucle empirique.
| Événement | Participants | Rôle du Scrum Team |
|---|---|---|
| Sprint Planning | Tout le Scrum Team | Définit Sprint Goal et Sprint Backlog. |
| Daily Scrum | Developers (PO/SM optionnel) | Inspecte la progression vers le Sprint Goal. |
| Sprint Review | Scrum Team + stakeholders | Inspecte l'Increment, adapte le Product Backlog. |
| Retrospective | Scrum Team uniquement | Inspecte l'équipe elle-même et adapte ses pratiques. |
| Sprint (conteneur) | Tout le Scrum Team | Vit la boucle empirique complète. |
Exemple complet — application bancaire
Une banque construit une application mobile de paiement. Le Scrum Team est composé de :
- 1 Product Owner issu du métier paiements.
- 1 Scrum Master dédié à temps plein.
- 6 Developers : 2 mobile iOS/Android, 2 back-end, 1 designer/UX, 1 ingénieur QA/sécurité.
| Membre | Pendant le Sprint | Comportement clé |
|---|---|---|
| Product Owner | Refine le Backlog, répond aux questions, prépare la Review. | Maximise la valeur, dit non aux distractions. |
| Scrum Master | Observe, coache, lève les obstacles, protège la time-box. | Sert l'équipe et l'organisation. |
| Developers | Construisent l'Increment, mettent à jour le Sprint Backlog, respectent la DoD. | S'entraident, livrent collectivement. |
Sprint Goal : « Permettre à un client de payer par QR code jusqu'à 200 €, en respectant les exigences de sécurité PCI. »
Collaboration pendant le Sprint :
- Daily Scrum : les Developers inspectent leur progression vers le Sprint Goal.
- Le PO clarifie une règle métier sur les plafonds quotidiens.
- Un Developer mobile aide le designer à valider une animation.
- Le Scrum Master débloque l'accès à l'environnement de pré-production.
Livraison de l'Increment : à la Sprint Review, l'équipe présente le paiement QR fonctionnel sur un téléphone réel, recueille le feedback des stakeholders (conformité, support client, marketing) et adapte le Product Backlog.
Amélioration continue : en Retrospective, l'équipe décide d'introduire une revue de sécurité au sein de la DoD pour les prochains Sprints — décision prise collectivement, sans validation hiérarchique externe.
Erreurs fréquentes au PSM I
| Erreur fréquente | Pourquoi c'est faux | Bon réflexe |
|---|---|---|
| Parler de « Development Team » | Terme obsolète depuis 2020. | Dire « Developers ». |
| Exclure le PO ou le SM du Scrum Team | Le Scrum Guide les inclut explicitement. | Le Scrum Team = PO + SM + Developers. |
| Imaginer un manager au-dessus du Scrum Team | Pas de hiérarchie interne. | Auto-management. |
| Créer des sous-équipes front/back/QA | Interdit par le Scrum Guide 2020. | Une seule équipe, cross-functional. |
| Fixer la taille à 9 ou exactement 10 | Le Guide dit « 10 ou moins ». | Mémoriser : ≤ 10. |
| Croire que les Developers sont uniquement des développeurs logiciels | Le terme couvre toute compétence. | Designer, QA, data, etc. inclus. |
| Croire que le SM dirige l'équipe | Le SM est un true leader au service. | Pas d'autorité hiérarchique. |
| Penser que la responsabilité est individuelle | L'Increment est livré collectivement. | Responsabilité collective. |
15 questions PSM I
FAQ — questions fréquentes
Retrouvez plus bas, dans la section FAQ structurée, les réponses aux dix questions les plus posées sur le Scrum Team.
Références
- Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland, novembre 2020.
- Scrum.org — documentation officielle, parcours PSM I.
- Ken Schwaber, co-auteur du Scrum Guide.
- Jeff Sutherland, co-auteur du Scrum Guide.
À lire aussi
Source officielle : Scrum Guide 2020.