Le guide eduScrum
“Les règles du jeu”
Développé par l'équipe eduScrum
Décembre 2013
Écrit par Arno Delhij et Rini van Solingen
Revu par Jeff Sutherland
Version 1.0 - Décembre 2013
Revu par : Jeff Sutherland
Traduction française par l'association Agile Toulouse
© 2013 équipe eduScrum, tous droits réservés Page 2
Table des matières
Introduction............................................................................................................................4
Le but du guide eduScrum.......................................................................................................5
La définition d'eduScrum.........................................................................................................5
Le cadre eduScrum..................................................................................................................6
La théorie derrière eduScrum..................................................................................................6
Transparence..........................................................................................................................................6
Inspection...............................................................................................................................................6
Adaptation.............................................................................................................................................7
L'équipe eduScrum..................................................................................................................8
Le Product Owner...................................................................................................................................8
1. Déterminer ce qui doit être appris................................................................................................8
2. Surveillance et amélioration de la qualité des résultats scolaires..................................................9
3. Évaluation des résultats scolaires..................................................................................................9
L'équipe d'étude...................................................................................................................................10
Taille de l'équipe d'étude.................................................................................................................11
L'eduScrumMaster...............................................................................................................................11
L'assistance de l'eduScrumMaster envers le Product Owner...........................................................12
L'assistance de l'eduScrumMaster envers l'équipe d'étude.............................................................12
Les événements eduScrum....................................................................................................13
Le Sprint...............................................................................................................................................13
La planification du Sprint......................................................................................................................14
Composition de l'équipe..................................................................................................................14
Les objectifs d'apprentissage...........................................................................................................15
La planification des tâches...............................................................................................................15
La mêlée...............................................................................................................................................16
La revue de Sprint.................................................................................................................................16
La rétrospective de Sprint.....................................................................................................................17
Les artefacts d'eduScrum.......................................................................................................18
Le Backlog............................................................................................................................................18
Le "Flip" (Scrum Board)........................................................................................................................19
La définition de "Fini"...........................................................................................................................19
La définition de "Fun"...........................................................................................................................20
Note de fin.............................................................................................................................21
Remerciements......................................................................................................................22
Les gens qui sont derrière eduScrum....................................................................................................22
La fondation eduScrum et les amis d'eduScrum...................................................................................23
© 2013 équipe eduScrum, tous droits réservés Page 3
Introduction
La plupart des lecteurs de ce document auront une expérience dans l'éducation et ne seront
probablement pas des habitués de Scrum. EduScrum est au carrefour de ces deux mondes : celui de
l'éducation et celui de Scrum. Scrum est un cadre pour le développement et la maintenance de
produits complexes. Il est, historiquement, largement utilisé dans la création de logiciels, au point de
devenir une des principales méthodes utilisées dans ce domaine. Cependant, de plus en plus de
professionnels explorent d'autres domaines où Scrum pourrait être utilisé.
Un de ces domaines est l'éducation. L'équipe eduScrum y a expérimenté Scrum dans une salle de
classe. Bien que les résultats scolaires attendus soient relativement faciles à prévoir, le processus pour
parvenir à ces résultats est tout aussi complexe que celui qui pilote le développement d'un logiciel. Les
trois piliers de Scrum sont la transparence, l'inspection et l'adaptation. Ce sont ces principes et la
notion d'auto-organisation qui ont poussé l'équipe à expérimenter ce cadre.
Pour tous ceux qui ont eu la chance d'en être les témoins, ce n'est plus un secret. Tous les autres seront
indubitablement surpris. EduScrum est un processus de co-création. Imaginez des étudiants qui se
sentent responsables de leur travail à faire sans que l'on ait besoin de les tenir pour responsables.
Imaginez des étudiants à qui ont ne dit ni quoi ni comment mais seulement quels sont les résultats
attendus. Imaginez qu'ils aient vraiment envie d'atteindre ces résultats. Les devoirs ne sont plus dictés
par l'enseignant mais ressentis comme nécessaires par les étudiants. Dans une classe qui utilise
eduScrum, on peut sentir l'énergie et l'ambiance positive.
Dans sa théorie, Dan Pink explique que, lorsque les tâches deviennent plus complexes et intéressantes,
les gens ne sont plus motivés par l'ancienne technique de la "carotte" et du "bâton". Les professionnels
du 21ème siècle en ont déjà fait l'expérience. Si nous voulons préparer nos enfants à être des
professionnels du 21ème siècle, nous devons leur donner l'autonomie, la maîtrise et la compréhension
de la finalité. C'est ce que va permettre eduScrum aux personnes qui le mettront en œuvre.
Ce guide contient les exigences minimales pour utiliser eduScrum avec succès. Tout ce qui était
susceptible d'être retiré a été retiré, mais rien de plus. Par conséquent tous les éléments présentés
dans ce guide sont requis pour travailler avec eduScrum. Si vous choisissez d'éliminer certains
éléments, c'est très bien. Mais ce ne sera plus eduScrum. Il est fréquent (et souhaitable) d'ajouter de
nouveaux éléments à ce cadre et c'est très bien tant que le cadre est respecté. Le cadre est léger et
offre beaucoup de place pour l'ajout de touches personnelles.
© 2013 équipe eduScrum, tous droits réservés Page 4
Le but du guide eduScrum
EduScrum est basé sur un Scrum (un cadre de travail pour l'élaboration et la maintenance de produits
complexes - Jeff Sutherland & Ken Schwaber 2013). EduScrum est un cadre pour aider les étudiants
dans un environnement où la responsabilité sur la façon d'apprendre leur est déléguée par les
enseignants.
Ce guide définit eduScrum. Il décrit les rôles, les événements et les artefacts d'eduScrum, ainsi que les
règles qui les lient. EduScrum a été développé par Willy Wijnands, Jan van Rossum et Ellen Reehorst.
Ce guide d'eduScrum est basé sur leurs expériences et leurs idées. Ensemble, ils approuvent ce guide
d'eduScrum. Ce guide a été inspiré par le guide original de Scrum écrit par Jeff Sutherland et Ken
Schwaber.
Dans eduScrum, l'apprentissage tient une place centrale : apprendre de manière plus intelligente,
améliorer la collaboration et mieux se connaître soi-même. Cette façon de travailler engendre aussi
plus de responsabilité, plus de plaisir et plus d'énergie, ce qui conduit à de meilleurs résultats dans des
délais plus courts. Cela amène les étudiants à grandir et ainsi renforcer leur confiance en eux-mêmes et
envers les autres. Les étudiants ont la possibilité de définir leur processus d'apprentissage dans des
limites et des objectifs pré-établis. Ce pouvoir qui leur est donné est la clef du système. EduScrum
améliore les résultats scolaires, mais il influe aussi sur le développement personnel des étudiants, ainsi
que sur leur capacité à travailler en équipe.
La définition d'eduScrum
EduScrum : un cadre dans lequel les étudiants peuvent s'atteler à des problèmes complexes
nécessitant une capacité d'adaptation tout en atteignant de manière efficace et créative les meilleurs
résultats possibles dans leurs objectifs d'apprentissage et de développement personnel. eduScrum est :
• Léger
• Facile à comprendre
• Difficile à maîtriser (car les équipes d'étude doivent y parvenir elles-mêmes)
La maîtrise est difficile car eduScrum définit seulement le "quoi" et pas le "comment". EduScrum n'est
ni un procédé, ni une technique pour coacher des étudiants : c'est un cadre dans lequel on peut
employer divers procédés et techniques. EduScrum met en évidence l'efficacité relative des plans et de
l'approche d'apprentissage choisie afin que les étudiants puissent s'améliorer par eux-mêmes.
EduScrum incite les étudiants à s'auto-organiser et produire un travail de la meilleure qualité possible
dans un délai imparti et avec des objectifs d'apprentissage définis.
Avec eduScrum, la qualité de la collaboration et du développement personnel est en constante
évolution durant l'année scolaire. Ayant le pouvoir sur leur processus d'apprentissage, les étudiants
évaluent en équipe sa qualité. Le pouvoir et la liberté laissés aux étudiants, combinés avec une
amélioration en continu, conduisent à une plus grande qualité. Dans une revue, l'accent est mis sur le
"quoi" (la matière étudiée). La rétrospective porte sur le “comment” (la collaboration, l'utilisation des
qualités de chacun, le développement personnel).
© 2013 équipe eduScrum, tous droits réservés Page 5
Le cadre eduScrum
Le cadre eduScrum, tout comme celui de Scrum, est constitué de rôles, d'événements, d'artefacts et de
règles. Chaque composante du cadre a un but précis et est essentielle au succès d'eduScrum.
Les tactiques d'utilisation d'eduScrum peuvent varier. Elles ne font pas partie de ce guide.
Les règles d'eduScrum sont les modalités qui lient événements, rôles et artefacts entre eux. Ces règles
sont décrites tout au long de ce document.
La théorie derrière eduScrum
EduScrum, tout comme Scrum est basé sur l'empirisme, c'est à dire sur l'idée que les connaissances
proviennent de l’expérience et qu’une prise de décision soit basée sur des faits connus. EduScrum
utilise une approche itérative et incrémentale pour optimiser la faisabilité des objectifs d'apprentissage
et pour contrôler le risque.
Trois piliers soutiennent l’implémentation d’un contrôle empirique de processus : la transparence,
l’inspection et l’adaptation.
Transparence
Les aspects importants du processus doivent être visibles à ceux qui sont responsables des résultats. La
transparence requiert la définition d’un standard commun pour ces aspects afin que les observateurs
partagent une compréhension commune de ce qui est observé. À titre d’exemple :
• Un langage commun décrivant le processus doit être partagé par tous les participants ; et,
• Ceux qui effectuent le travail et ceux qui en acceptent le résultat doivent partager une
définition commune de « Fini ».
EduScrum porte une attention particulière à la valeur ajoutée. La valeur est définie comme étant
l'ensemble des résultats d'apprentissage individuels, le développement personnel et les réalisations en
coopération. Le cadre eduScrum est destiné à fournir la transparence au processus d'apprentissage,
transparence nécessaire pour aider les étudiants à prendre les bonnes décisions afin de maximiser la
valeur.
Inspection
Les utilisateurs d'eduScrum doivent fréquemment inspecter les artefacts eduScrum et l'état
d'avancement par rapport à des objectifs d'apprentissage afin de détecter les écarts indésirables. La
fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces inspections sont bénéfiques
lorsqu’elles sont effectuées rapidement dans la salle de classe et conjointement par les enseignants et
les étudiants.
© 2013 équipe eduScrum, tous droits réservés Page 6
Adaptation
Si un étudiant ou un enseignant détermine qu’un ou plusieurs aspects du processus dérivent hors des
limites acceptables et/ou que les résultats ne seront pas acceptables, la façon de procéder doit être
ajustée. Un ajustement doit être fait dès que possible afin de minimiser le risque d’autres dérives.
EduScrum prescrit six occasions formelles d’inspection et d’adaptation, telles que décrites dans la
section Événements Scrum de ce document :
• Formation de l'équipe
• Planification de Sprint
• Mêlée (au début de chaque cours)
• Revue de Sprint (examen, présentation orale ou écrite, expérience, ou une combinaison de
plusieurs de ces éléments)
• Rétrospective de Sprint (fonctionnement de l'équipe)
• Réflexion personnelle
© 2013 équipe eduScrum, tous droits réservés Page 7
L'équipe eduScrum
Une équipe eduScrum comprend un enseignant (le propriétaire du produit ou Product Owner) et une
équipe d'étude de quatre étudiants. Un des quatre étudiants de l'équipe occupe le rôle
d'eduScrumMaster de l'équipe d'étude. Les équipes d'étude sont auto-organisées et pluridisciplinaires.
Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur travail, au lieu d’être
dirigées par des personnes externes à l'équipe d'étude (par exemple, les enseignants). Les équipes
pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre de
personnes n’appartenant pas à l’équipe. Les étudiants se répartissent eux-mêmes en équipes d'étude
en fonction de leurs compétences et de leurs qualités individuelles. Même si chaque équipe est
responsable de ses propres résultats, et donc, en ce sens, indépendante, elle peut utiliser des idées et
des informations provenant d'autres équipes. La coopération inter-équipes est encouragée. EduScrum
définit un modèle d’équipe optimisant l'autonomie, la collaboration, la flexibilité, la créativité, la
motivation et la productivité.
Les équipes eduScrum produisent des résultats d'apprentissage de manière itérative et incrémentale,
maximisant ainsi les occasions de rétroaction. Les livraisons incrémentales de résultats d'apprentissage
“Finis” assurent que l'atteinte des objectifs d'apprentissage est toujours possible.
Le Product Owner
Le Product Owner détermine les objectifs d'apprentissage et est également responsable de l'évaluation
et du suivi des résultats. Il ou elle aidera également les étudiants et les équipes dans leur processus
d'apprentissage. Le Product Owner peut, entre autres, conseiller l'utilisation de certains documents,
répondre à des questions ou fournir des exemples. Le Product Owner doit également encourager la
coopération inter-équipes. La manière dont les organisations, les équipes et les individus mettent cela
en œuvre dépend de leur propre approche organisationnelle et de leur stratégie.
En tant que Product Owner, l'enseignant se concentre explicitement sur la matière étudiée. Le Product
Owner a la responsabilité :
1. de déterminer ce qui doit être appris ;
2. du suivi et de l'amélioration de la qualité des résultats scolaires ;
3. de l'évaluation des résultats scolaires (en se basant sur la définition de "Fini" et sur les critères
d'acceptation)
1. Déterminer ce qui doit être appris
Le Product Owner est responsable des résultats scolaires mesurables : contrôles, passage dans la classe
supérieure, résultats aux examens. Le Product Owner garantit que les diverses parties prenantes,
étudiants, parents et autorités de tutelle soient satisfaits des résultats scolaires.
Par conséquent, le Product Owner a la responsabilité de définir ce qui doit être appris et de ce qui est
prioritaire pour un sujet d'étude donné. Pour suivre et évaluer les progrès et les résultats, le Product
Owner définira les critères d'acceptation (tels que les compétences à acquérir, les contenus attendus,
© 2013 équipe eduScrum, tous droits réservés Page 8
etc.) avant chaque période.
2. Surveillance et amélioration de la qualité des résultats scolaires
En focalisant sur les objectifs d'apprentissage, le Product Owner doit surveiller, contrôler et améliorer
la qualité des résultats scolaires. Pour cela, il utilise deux critères : la définition du "Fini", établie par
l’Équipe d’Étude, et les critères d'acceptation définis par lui-même.
Critères d’acceptation
Pour surveiller la qualité de ce qui doit être appris, le Product Owner définit des critères d’acceptation.
Ils sont déterminés au préalable et partagés avec les Équipes d’Étude. Par exemple, ils peuvent contenir
les résultats minimums aux évaluations, le type, la taille et la durée des présentations ou d'autres
exigences sur les résultats. L’Équipe d’Étude doit respecter les critères d’acceptation. Les étudiants
doivent aussi définir les activités de telle sorte qu’elles soient conformes à ces critères d’acceptation.
La Définition de Fini (DdF)
Pour garantir la qualité des objectifs d'apprentissage l’Équipe d’Étude doit définir la Définition de Fini.
Avant de débuter elle doit déterminer quand le travail est "Fini". Les équipes inexpérimentées feront
appel au Product Owner pour les aider. Les équipes expérimentées les définiront de façon autonome.
Ainsi les Équipes d’Étude continueront à s'améliorer dans la définition de leur propres critères de
qualité.
3. Évaluation des résultats scolaires
Le Product Owner évalue, au nom des parties prenantes (les parents, le conseil de l'école et les
étudiants), la qualité des résultats scolaires. Il évalue et juge en même temps les étudiants (avec, par
exemple, des tests écrits) et les équipes (en évaluant le travail réalisé).
Le Product Owner est le seul responsable de la gestion du Backlog qui consiste à :
• fournir l’explication initiale d’eduScrum aux étudiants (une seule fois, en 2 heures),
• définir les objectifs des Sprints et ce qu’ils signifient ;
• définir et expliquer les critères d’acceptation. Expliquer clairement quels critères déterminent si
un but d’apprentissage a été acquis afin de déterminer quand la classe peut commencer à
travailler de façon indépendante (expériences, rédactions, présentations, etc.) ;
• Aider la classe pour les prochains objectifs et critères d’acceptation en lien avec l’enseignement,
les documents d’information pour répondre à toute question ;
• Surveiller que tous suivront le processus eduScrum.
A la différence de Scrum, le Product Owner d'eduScrum n'est pas lié à l'équipe mais à la matière. Il
intervient avec plusieurs équipes dans de multiples classes. Les équipes peuvent avoir plusieurs
Product Owners lorsqu'elles travaillent sur des apprentissages interdisciplinaires. Dans ce cas il y a un
Product Owner par matière.
Les étudiants ont parfois la liberté, dans leur cursus scolaire, de définir partiellement leurs propres
objectifs d'apprentissage. Le Product Owner reste toujours responsable du critère d'acceptation final,
© 2013 équipe eduScrum, tous droits réservés Page 9
mais le lien avec le programme, et les éventuels examens, est plus souple.
En tant que Product Owner, l'enseignant est un servant leader auprès des équipes d'étude. Le Product
Owner est aussi responsable de la diffusion de l'approche eduScrum. Le Product Owner doit faire en
sorte qu'eduScrum soit compris et correctement mis en œuvre et en ce sens se concentre sur la façon
dont toutes les Équipes d’Étude travaillent et collaborent dans une classe. Pour s'en assurer, le Product
Owner fait les choses suivantes:
• explique ce qu'est eduScrum, quelle est sa pertinence et comment cela fonctionne (une fois)
• s'assure que les équipes d'étude sont correctement formées en fonction des compétences
complémentaires
• s'assure que le processus eduScrum est bien suivi par l'équipe d'étude en respectant la théorie
et les règles d'eduScrum
• si nécessaire, apporte des compléments d'information, explications, démonstrations et fournit
des retours positifs, etc.
• encourage l’énergie, le plaisir et une montée en compétences (peut être délégué à
l'eduScrumMaster)
• protège les équipes d'étude des interruptions externes (peut être délégué à l'eduScrumMaster)
• encourage les équipes d'étude à résoudre les obstacles rapidement et de manière autonome;
les obstacles qui dépassent le pouvoir d'une équipe peuvent être résolus par le Product Owner
(peut être délégué à l'eduScrumMaster)
En outre, le Product Owner doit accompagner et guider les étudiants qui sont eduScrumMasters au
sein de leurs équipes respectives (voir eduScrumMaster). Le Product Owner encourage aussi la
collaboration entre les équipes.car les équipes d'étude peuvent apprendre beaucoup du partage de
leurs succès et de leurs échecs.
L'équipe d'étude
L'équipe d'étude est constituée d'étudiants autonomes qui collaborent afin d'atteindre les objectifs
d'apprentissage requis à la fin du Sprint, en accord avec les critères d'acceptation définis. Les membres
de l'équipe sont responsables ensemble, en tant qu'équipe, de la conformité avec les critères
d'acceptation.
Les équipes d'étude sont structurées et habilitées par le Product Owner de manière à pouvoir
s'organiser et gérer leur propre travail. Grâce à quoi, l'efficacité et l'efficience1
sont grandement
améliorées ainsi que l'expérience d'apprentissage et le développement personnel.
1 Si l'efficacité est réaliser les actions adéquates, l'efficience est réaliser les actions de façon correcte
© 2013 équipe eduScrum, tous droits réservés Page 10
Les équipes d'étude présentent les caractéristiques suivantes :
1. Elles sont auto-organisées. Personne (pas même le Product Owner) ne peut dire à l'équipe
d'étude comment elle doit réaliser les objectifs d'apprentissage.
2. Elles sont pluridisciplinaires, avec toutes les compétences nécessaires pour atteindre les
objectifs d'apprentissage et contribuer au développement personnel de ses membres.
3. Les membres d'une équipe d'étude peuvent posséder des compétences particulières ou des
domaines de prédilection, mais la responsabilité repose sur l'équipe d'étude dans son
ensemble.
4. Les membres d'une équipe d'étude peuvent décider par eux-mêmes s'ils souhaitent contribuer
en fonction de leurs compétences ou s'ils préfèrent en développer de nouvelles.
5. L'équipe d'étude mesure ses progrès et son niveau de qualité en se basant sur les critères
d'acceptation et la Définition de Fini.
Taille de l'équipe d'étude
La taille idéale de l'équipe d'étude est assez petite pour être gérable et assez grande pour pouvoir
réaliser une quantité de travail significative. En règle générale, les équipes sont constituées de quatre
membres. Avoir moins que trois membres conduit à moins d'interaction ainsi qu'à moins de diversité
dans les compétences. Au contraire, avoir plus de cinq membres dans l'équipe requiert trop de
coordination. Les grandes équipes génèrent trop de complexité pour être pilotée par un processus
empirique. L'enseignant n'est pas compté dans la taille de l'équipe d'étude.
L'eduScrumMaster
Au sein d'une équipe d'étude, l'un des membres assume le rôle d'eduScrumMaster de cette équipe.
L'eduScrumMaster est au service de l'équipe tout en en faisant également partie. Il aide son équipe à
fonctionner de façon optimale - mais ne dirige pas l'équipe.
L'eduScrumMaster a un rôle plus restreint au sein d'eduScrum qu'un ScrumMaster au sein de Scrum.
C'est dû au fait que le Product Owner récupère plusieurs de ses responsabilités. Au fur et à mesure que
l'eduScrumMaster acquiert de l'expérience, il prend plus de responsabilités tandis que celles du
Product Owner s'amenuisent.
Lors du cérémonial de formation de l'équipe, les eduScrumMasters sont choisis en premier par le
Product Owner ou par la classe. A leurs tours, les eduScrumMasters choisissent les membres de leur
équipe au regard de la complémentarité de leurs compétences.
Au sein de l'équipe d'étude, l'eduScrumMaster a la responsabilité du Flip (un synonyme pour le Scrum
Board). L'eduScrumMaster s'assure que le Flip est accessible et à jour. Néanmoins, la réalisation du
travail est de la responsabilité de l'équipe dans son ensemble. L'eduScrumMaster assiste également le
Product Owner et l'équipe d'étude.
© 2013 équipe eduScrum, tous droits réservés Page 11
La mise en œuvre du rôle d'eduScrumMaster incombe initialement au Product Owner. Cependant, au
fur et à mesure de la progression de l'équipe, davantage de responsabilités seront déléguées à
l'eduScrumMaster.
L'assistance de l'eduScrumMaster envers le Product Owner
L'eduScrumMaster assiste le Product Owner de différentes façons, par exemple :
• en rendant le Flip disponible et en s'assurant qu'il est à jour pour que l'avancement soit
transparent
• en facilitant les événements eduScrum en fonction des besoins ou des demandes.
L'assistance de l'eduScrumMaster envers l'équipe d'étude
L'eduScrumMaster assiste l'équipe d'étude de différentes façons, à minima :
• en rendant le Flip disponible et en s'assurant qu'il est à jour pour que l'avancement soit
transparent
• en assurant l'exécution correcte d'eduScrum (initialisation,facilitation et exécution correcte des
événements eduScrum, utilisation correcte de l'outillage).
• en facilitant les échanges entre les différentes Équipes d’Étude.
© 2013 équipe eduScrum, tous droits réservés Page 12
Les événements eduScrum
Les événements proposés sont utilisés dans eduScrum pour susciter la régularité et la prévisibilité. Tous
les événements sont délimités dans le temps. Chaque événement a une durée maximale, afin d'utiliser
juste le temps approprié dans le processus sans gaspillage.
À l'exception du Sprint, qui est un conteneur pour tous les autres événements, chaque événement
dans Scrum offre une opportunité formelle de contrôler et d'adapter quelque chose. Ces événements
sont particulièrement conçus pour favoriser de façon déterminante la transparence et le contrôle. Ne
pas inclure l'un de ces événements conduit à moins de transparence, et à moins d'opportunités de
contrôle et d'adaptations.
Le Sprint
Le Sprint est au cœur d'eduScrum. C'est un ensemble cohérent de pratiques d'apprentissage destiné à
des objectifs précis. Un Sprint peut être une série de leçons riches en contenu, un projet, le chapitre
d'un livre, etc. En général les Sprints coïncident avec les périodes scolaires, mais ce n'est pas
obligatoire.
Un Sprint a une durée prédéterminée, en général de 2 mois maximum. Si l'horizon est plus lointain, il
devient difficile aux équipes d'étude de planifier2
correctement le travail et d'avoir une vue d'ensemble
de la complexité.
Le Sprint débute par la réunion de planification de Sprint et de formation de l'équipe. Les équipes
d'étude déterminent indépendamment ce qu'elles vont faire au cours de la période. C'est toujours
l'équipe d'étude qui détermine le « comment ».
Chaque Sprint se compose :
• de la réunion de planification de Sprint, comprenant la formation de l'équipe
• de la mêlée, au début de chaque cours
• de la réalisation des engagements et des tâches du Sprint
• de la revue de Sprint
• de la rétrospective de Sprint et la Réflexion personnelle
Au cours du Sprint :
• la composition de l'équipe d'étude reste inchangée
• le périmètre reste inchangé. Le niveau de qualité peut être clarifié et renégociée entre le
Product Owner et l'équipe d'étude au fur et à mesure des apprentissages
Le Sprint s'achève par une revue et une rétrospective, pour contrôler le travail fourni et identifier les
axes d'amélioration.
2 Certaines équipes, en particulier celles qui débutent dans eduScrum, trouvent difficile de planifier un Sprint
complet dès le début. Elles peuvent commencer par un macro-planning, qu'elles affinent au fur et à mesure de leur
progression et de leur meilleure visibilité
© 2013 équipe eduScrum, tous droits réservés Page 13
Au cours du Sprint, le Product Owner surveille et contrôle régulièrement si chaque équipe atteint la
qualité souhaitée. Certaines équipes peuvent ajouter au Sprint un événement supplémentaire, planifié
régulièrement et limité dans le temps, pour s'assurer que l'Inspection et l'Adaptation ont bien lieu au
cours du Sprint. Tout comme dans Scrum, nous avons à eduScrum pour devise : « tester pendant le
Sprint ». Le Product Owner rappelle régulièrement que les livraisons doivent être testées, et encourage
les équipes d'étude à le faire elles-mêmes. Les équipes d'étude peuvent imaginer toutes sortes de
méthodes pour le faire, comme se tester mutuellement, ou faire des jeux ou des compétitions
éducatives.
En tant que Product Owner, l'enseignant surveille l'avancement de chaque équipe. Le Flip et les
Burndown Charts en fournissent une visualisation rapide.
Annulation d'un Sprint – impossible dans eduScrum.
Dans eduScrum, un Sprint ne peut pas être annulé, à l'inverse de Scrum. Il est possible de fixer des
missions supplémentaires (périmètre) afin d'atteindre le résultat. Ceci devrait rester exceptionnel. Un
enseignant peut également revenir par moments à une approche plus classique pour permettre
l'atteinte du résultat. Ceci peut avoir lieu pour toutes les équipes, ou par équipe d'étude.
La planification du Sprint
La planification du Sprint se déroule au début du Sprint. Elle comprend trois parties : la composition de
l'équipe, les objectifs d'apprentissage et la planification des tâches.
Composition de l'équipe
En plus des événements Scrum, eduScrum propose deux événements additionnels, l'un d'entre eux est
la composition de l'équipe. Un composition d'équipe réalisée minutieusement en se basant sur les
qualités et les compétences de chacun est essentielle pour de meilleures performances
d'apprentissage. Le travail à suivre étant varié, il nécessite des équipes combinant autant de qualités,
connaissances et compétences que possible.
Pour obtenir de bonnes compositions d'équipe, les critères suivant sont importants :
• des membres aux qualités complémentaires ;
• un équilibre entre hommes et femmes ;
• des compositions différentes de celles des Sprints précédents ;
• des compositions basées sur l'amitié entre les membres ne sont pas souhaitables.
Pendant la composition des équipes, le Product Owner ou l'ensemble de la classe commence par
désigner les eduScrumMasters. Ensuite, chaque eduScrumMaster choisit une équipe aux compétences
complémentaires. L'événement de composition des équipes fait partie de l'événement de planification
de Sprint.
© 2013 équipe eduScrum, tous droits réservés Page 14
Les objectifs d'apprentissage
Les objectifs d'apprentissage donnent aux équipes d'étude la flexibilité nécessaire quant au contenu
qui sera produit pendant le Sprint et à la manière d'y parvenir. Le Product Owner décrit ce qu'il attend
de l'équipe à la fin du Sprint ; les objectifs d'apprentissage dépendent principalement de la matière
étudiée et découlent des programmes, et des éventuels examens, définis par l'éducation nationale.
Pendant son travail, l'équipe d'étude garde un œil sur les objectifs d'apprentissage. Les devoir et les
tâches sont effectués dans le but d'atteindre ces objectifs d'apprentissage. Si l'équipe d'étude se rend
compte que le travail à réaliser diverge de celui qu'ils avaient planifié, les étudiants redéfiniront, avec
l'aide du Product Owner, leurs devoirs et tâches afin que ceux-ci correspondent à leurs objectifs
d'apprentissage.
Les objectifs d'apprentissage font partie du programme et, en tant que tels, constituent des jalons dans
la progression des étudiants.
La planification des tâches
Le travail qui sera effectué au cours d'un Sprint est défini pendant la planification du Sprint. La création
de ce plan est un travail collaboratif de chaque équipe d'étude.
En premier lieu, l'enseignant présente un aperçu de la mission, du nombre de leçons, du nombre de
leçons par Sprint, des dates importantes, des modèles d'évaluation, etc. Le Product Owner définit les
frontières de l'espace appartenant aux étudiants et à l'intérieur duquel ils peuvent créer leur planning.
La réunion de planification de sprint est limitée à deux heures pour un sprint d'approximativement
deux mois. Cette durée est souvent à peu près la même pour des sprints plus courts.
La réunion de planification de sprint répond aux questions suivantes :
• Qu'est il attendu de la part de l'équipe d'étude dans ce sprint; quels sont les objectifs
d'apprentissage, quels matériels pédagogiques vont être couverts, quels sont les critères
d'acceptation et quelles sont les dépendances ?
• Que doit il être accompli pour atteindre les objectifs d'apprentissage, dans quel ordre et par qui
?
Le Product Owner présente les objectifs d'apprentissage aux équipes d'étude et leur explique de
manière à ce que toutes les équipes d'étude et tous les membres aient une bonne idée de ce qui est
attendu de leur part durant ce sprint. Les objectifs d'apprentissage doivent avoir été suffisamment
expliqués de façon à ce que l'équipe d'étude puisse les détailler de façon autonome lors de la réunion
de planification.
Après l'explication des objectifs d'apprentissage par le Product Owner, il est du ressort de l’équipe
d'étude de décider des activités requises. En principe, l'équipe d'étude est responsable de la taille des
tâches et des livraisons partielles.
© 2013 équipe eduScrum, tous droits réservés Page 15
Aussitôt que ce qui doit être fait est assez clair, l'équipe d'étude commence à organiser
chronologiquement les tâches et les livraisons partielles en se basant sur leur propre compréhension et
sur les critères d'acceptation du Product Owner.
Aussitôt que les tâches et livraisons partielles ont été ordonnancées de façon chronologique, les
premières subdivisions en tâches peuvent être réalisées. Lors de cette session de planification,
seulement une première esquisse sera effectuée. Par la suite, le processus d'inspection et d'adaptation
mènera continuellement à mettre à jour la compréhension et probablement à modifier la planification
et la division du travail.
A la fin de la réunion de planification, l'équipe d'étude doit être capable d'expliquer au Product Owner
comment, en tant qu'équipe auto organisée, ils ont planifié d'atteindre les objectifs d'apprentissage et
comment ils vont réaliser les objectifs du sprint.
La mêlée
La mêlée est un événement limité à 5 minutes. Elle permet à l'équipe d'étude de synchroniser ses
activités et de les planifier jusqu'à la prochaine réunion. La mêlée a lieu au début de chaque cours. Il
s'agit de contrôler le travail réalisé depuis la dernière mêlée, et de prévoir celui à réaliser jusqu'à la
prochaine.
La mêlée a lieu toujours au même moment, au début du cours, ceci afin de simplifier les choses et
d'établir un rythme régulier. Pendant la mêlée, chaque membre de l'équipe d'étude répond aux
questions suivantes :
• Qu'ai-je fait depuis le dernier cours pour permettre à l'équipe d'atteindre l'objectif du Sprint ?
• Que vais-je faire pendant ce cours pour permettre à l'équipe d'atteindre l'objectif du Sprint ?
• Quels sont les obstacles qui entravent, pour moi ou pour l'équipe, l'atteinte de l'objectif du
Sprint ?
L'équipe d'étude utilise la mêlée pour évaluer et surveiller l'avancement dans le respect des objectifs
d'apprentissage, pour planifier le travail et pour se mettre d'accord sur le travail à réaliser. La mêlée
permet de maximiser la probabilité qu'une équipe d'étude atteigne ses objectifs d'apprentissage avec
la meilleure qualité possible. L'équipe d'étude doit pouvoir expliquer au Product Owner comment elle
s'organise pour atteindre les objectifs d'apprentissage, et quelles activités restent à faire pour le Sprint.
L'eduScrumMaster s'assure que l'équipe d'étude fasse réellement la mêlée, mais c'est l'équipe d'étude
qui est responsable de sa tenue. L'eduScrumMaster aide l'équipe d'étude à limiter la mêlée à 5
minutes.
Les mêlées améliorent la communication, permettent d'identifier et de lever les entraves au
développement, soulignent et encouragent les prises de décision rapides et améliorent, pour l'équipe
d'étude, sa connaissance du projet. C'est une réunion très importante pour « Inspecter et Adapter ».
La revue de Sprint
La revue de Sprint se déroule à la fin du Sprint et correspond à l'examen de fin de période. L'équipe
© 2013 équipe eduScrum, tous droits réservés Page 16
d'étude montre ce qu'elle a appris au cours du dernier Sprint. Les modalités dépendent des objectifs
d'apprentissage et des critères d'acceptation.
Au cours du Sprint il est nécessaire de « Inspecter et Adapter » aussi souvent que possible, sans
entraver le processus d'apprentissage. En général on observe que plus souvent l'inspection a lieu,
meilleures sont les chances de succès. La fréquence des inspections et la façon dont ils seront évalués
doivent être partagées avec l'équipe d'étude au début du Sprint, lors de la planification du Sprint. Ces
inspections aident à juger des progrès et de la qualité au regard des objectifs d'apprentissage. Ils ont
pour but de récolter le plus de retour possible sur les tâches réalisées.
La rétrospective de Sprint
La rétrospective de Sprint est une occasion pour l'équipe d'étude de s'auto-inspecter. La rétrospective
de Sprint est effectuée aussitôt que possible après la revue de Sprint. La rétrospective doit être réalisée
minutieusement. Elle sert aux membres de l'équipe à définir un plan d'amélioration et à se préparer
pour le Sprint suivant. La rétrospective devrait se tenir aussitôt que les résultats de l'examen final sont
disponibles. Tout retard dans la tenue de la rétrospective constitue une occasion manquée pour
l'amélioration de l'équipe.
Le but de la rétrospective de Sprint est :
• d'analyser le déroulement du dernier sprint par rapport aux relations entre les personnes et
aux processus et outils utilisés.
• d'identifier ce qui s'est bien passé et ce qui pourrait être amélioré.
• de définir un plan d'améliorations.
La rétrospective de Sprint se déroule en trois parties :
1. Les étudiants évaluent les méthodes de travail de l'équipe et identifient les points
d'amélioration ;
2. Ensuite, chaque étudiant évalue individuellement les compétences et les possibilités de
progression de chacun de membres de l'équipe, y compris lui-même ;
3. L'équipe discute de ce qu'elle devrait cesser de faire.
En faisant cela, les étudiants apprennent ensemble à apprendre de manière efficace et efficiente. La
rétrospective de Sprint est ainsi un élément essentiel du processus d'eduScrum et elle ne devrait
jamais être ignorée. Elle se tient après la fin de la totalité du Sprint.
L'équipe d'étude répond individuellement et collectivement aux quatre questions suivantes :
1. Qu'est-ce qui s'est bien passé ?
2. Qu'est-ce que l'on aurait pu ou dû faire mieux ?
3. Que ne devrions-nous plus jamais faire ?
4. Quelle action mettrons-nous en place dans le prochain Sprint ?
© 2013 équipe eduScrum, tous droits réservés Page 17
Les artefacts d'eduScrum
Les artefacts d'eduScrum représentent soit du travail, soit de la valeur fournissant ainsi de la
transparence et des opportunités pour l'inspection et l'adaptation. Les artefacts d'eduScrum sont
spécialement conçus pour maximiser la transparence d’informations essentielles afin que les équipes
d'étude atteignent leurs objectifs d'apprentissage.
Le Backlog
Le Backlog est une liste ordonnée de tous les objectifs d'apprentissage correspondant au programme
défini par l'éducation nationale pour l'ensemble du cours considéré.
Le Product Owner est responsable du contenu, de la disponibilité et de l'ordonnancement du Backlog.
Contrairement à Scrum où le Backlog n'est jamais complet, dans eduScrum le programme et les
objectifs d'apprentissage sont connus à l'avance. Le programme est prédéterminé ; les objectifs
d'apprentissage peuvent varier mais sont souvent bien connus. Toutefois, les méthodes de travail sont
continuellement ajustées en fonction de ce que l'on découvre durant l'apprentissage, conformément
au principe de Scrum “Inspection et Adaptation”. Ainsi, le Backlog s'adapte aux méthodes de travail : il
change en permanence pour correspondre à ce dont les étudiants ont besoin pour coopérer et pour
comprendre les divers supports.
Le Backlog est ordonné par rapport au programme car les objectifs d'apprentissage doivent
correspondre au programme défini par l'éducation nationale. Les éléments les plus prioritaires du
Backlog correspondent au prochain Sprint tandis que les moins prioritaires concernent ce qui viendra
plus tard. Les éléments les plus prioritaires sont plus clairs et bien plus détaillés que les moins
prioritaires. Plus un élément est éloigné dans le temps, moins il est détaillé. Les éléments du Backlog
que les équipes d'étude vont aborder dans le prochain Sprint sont finement décomposés de telle sorte
que chacun d'entre eux puisse être "Fini" dans la durée d’un Sprint. Cela signifie que les supports
d'apprentissage ont été suffisamment et clairement définis de telle sorte que les équipes d'étude
puissent obtenir de bons résultats dans la période à venir.
© 2013 équipe eduScrum, tous droits réservés Page 18
Le "Flip" (Scrum Board)
Le “Flip”3
est un support mobile permettant de visualiser l'ensemble des tâches (recherches, quiz,
présentations, rédactions, etc.) que l'équipe d'étude effectue dans le Sprint en cours. Le Flip est une
représentation chronologique du travail dans le Sprint. Les tâches sont disposées en fonction de leur
état : "A faire", "En cours" et "Fini". Le Flip donne une vue d'ensemble de toutes les tâches permettant
d'atteindre les objectifs d'apprentissage. Le Flip fournit aussi une vue d'ensemble du plan d'exécution.
Il montre où en est exactement l'équipe d'étude par rapport à ce qui a déjà été fait et ce qui reste à
faire. Par conséquent, le Flip permet aussi de prévoir si l'équipe d'étude est en bonne voie pour
atteindre ses objectifs d'apprentissage. Le Flip doit être en permanence mis à jour de telle sorte qu'il
montre à tout instant la progression exacte de l'équipe d'étude. La mise à jour doit se faire au moins
avant chaque mêlée.
Une autre caractéristique du Flip est de favoriser la transparence de la progression. Dans ce sens, le Flip
doit être visible par toutes les équipes d'étude pendant chaque rencontre.
Le Flip est juste suffisamment détaillé pour permettre de comprendre les changements en cours
pendant la mêlée. Les étudiants modifient le Flip tout au long du Sprint, il évolue donc au cours du
Sprint. Ainsi, le Flip peut être modifié à tout instant en fonction de ce que l'équipe a découvert (comme
ajouter de nouvelles tâches).
Quand un nouveau travail est nécessaire, l'équipe d'étude l'ajoute au Flip. Lorsque des éléments du
Flip ne sont plus jugés nécessaires, il sont enlevés. Pendant un Sprint, seule l'équipe d'étude peut
changer le Flip. Le Flip doit être extrêmement visible. C'est une sorte de cliché temps réel du travail que
l' équipe d'étude planifie d'accomplir durant le Sprint, et il est de la responsabilité de l'équipe d'étude
seule.
Suivi de la progression du Sprint
A n'importe quel moment dans un Sprint, le travail restant à faire visible sur le Flip doit pouvoir être
calculé. L'équipe d'étude doit mettre à jour cette valeur au moins à chaque mêlée. L'équipe d'étude,
avec le Product Owner, projette la probabilité d'atteindre l'objectif d'apprentissage, fondée sur le statut
des tâches restantes. En faisant le suivi du travail restant lors du Sprint, l'équipe d'étude peut gérer ses
progrès.
La définition de "Fini"
Quand un objectif d'apprentissage est décrit comme "Fini", tout le monde doit comprendre ce que ce
«Fini» signifie. Bien que cela varie sensiblement d'une équipe d'étude à une autre, les membres
doivent, de manière transparente, avoir une compréhension commune de ce que signifie qu'un travail
est achevé. Cette "Définition de Fini" est utilisée par l'équipe d'étude pour déterminer quand le travail
est terminé pour chaque objectif d'apprentissage.
3 Abbréviation de "Flipchart", un tableau composé de feuilles que l'on appelle parfois aussi, en français,
"Paperboard"
© 2013 équipe eduScrum, tous droits réservés Page 19
Objectif d'apprentissage
Chaque Sprint correspond à un ensemble d'objectifs d'apprentissage. À la fin d'un Sprint, ces objectifs
d'apprentissage doivent être "Finis", ce qui signifie qu'ils doivent répondre aux critères d'acceptation
prédéfinis. Ces critères peuvent correspondre à une note qui évalue la compréhension de l'objectif
d'apprentissage. Par définition, une note suffisante pour passer à la prochaine période ou année
scolaire (par exemple, un 10 sur une échelle de 0 à 20), ne signifie pas compréhension de l'objectif
d'apprentissage.
La même définition guide l'équipe d'étude lors de la planification et la décomposition au cours de la
réunion de planification du Sprint. Le but de chaque Sprint est d'atteindre des objectifs d'apprentissage
qui adhèrent à la définition actuelle de «Fini» de l'équipe étudiante, et à la meilleure qualité possible.
Les questions importantes pour arriver à une définition utile de «Fini» sont :
• Comment vérifiez-vous que vous avez vraiment fini ?
• Qu'est-ce qui est fait exactement, quels critères doivent être tenus ?
• Mais aussi, quand n'est-ce pas fini ?
Les équipes d'étude sont elles-mêmes responsables de la mise en place de leur définition de «Fini».
Comme la mise en place d'une définition du "Fini" fait également partie du processus d'apprentissage,
il peut être modifié en fonction des décisions des rétrospectives. De cette façon, de nouvelles idées
peuvent être incluses dans le processus pour obtenir de meilleurs résultats.
La définition de "Fun"
Un complément à la définition de "Fini" est la définition de "Fun". Le plaisir est un important facteur de
motivation pour les étudiants et il est donc essentiel pour obtenir de meilleurs résultats
d'apprentissage. Ainsi, les élèves devraient également indiquer ce dont ils ont besoin pour s'amuser
pendant le travail qu'ils font. «Besoin» dans ce contexte peut être interprété dans le sens le plus large
du mot : ce qui devrait être là pour assurer un travail agréable et joyeux. Souvent les résultats d'une
rétrospective offrent des indices pour la définition de "Fun". La définition de Fun est également un
"document vivant" et peut être modifié ou étendu fréquemment.
© 2013 équipe eduScrum, tous droits réservés Page 20
Note de fin
EduScrum est gratuit et est offert par ce guide. Les rôles, les artefacts, les événements, et les règles de
eduScrum sont immuables, et bien que la mise en œuvre de parties d'eduScrum soit possible, le
résultat ne sera pas eduScrum. EduScrum n'existe que par l'ensemble de ses éléments et fonctions,
comme un conteneur pour d'autres techniques, méthodes et pratiques.
Ce guide sera régulièrement révisé. Si vous avez des idées sur la façon dont ce guide peut être
amélioré, merci de les partager avec nous en écrivant à :
eduscrumguide@gmail.com
© 2013 équipe eduScrum, tous droits réservés Page 21
Remerciements
Les gens qui sont derrière eduScrum
"Nous avons une grande confiance dans les jeunes. Nous sommes convaincus qu'ils en veulent plus et
sont plus capables qu'eux-mêmes, ou de nombreux adultes, croient. EduScrum garantit que les
étudiants obtiennent le meilleur d'eux-mêmes et de leur équipe. C'est ce qui rend l'éducation valable
pour toute personne impliquée ! Le résultat est que les jeunes se respectent et s'acceptent les uns les
autres comme ils sont. Donc, nous espérons que nous pouvons contribuer à un monde meilleur."
Scrum, développé par Jeff Sutherland et Ken Schwaber, est la base du cadre eduScrum. Ce cadre a été
adapté pour l'éducation par Willy Wijnands, Jan van Rossum et Ellen Reehorst qui ont tous une
expérience dans l'éducation.
Willy Wijnands est enseignant de physique-chimie à l'Ashram College à
Alphen aan den Rijn, et enseignant d’aïkido. 'Je donne aux étudiants la
propriété de leur propre processus d'apprentissage, mais , encore plus
important, la confiance. Les étudiants apprennent la responsabilité par la
liberté et l'espace qu'ils reçoivent. Le résultat est que les élèves s'impliquent,
font plus et obtiennent de meilleurs résultats ; en un mot : étonnant !'
Jan van Rossum est enseignant de chimie, doyen à l'Ashram College à Alphen
aan den Rijn et coach à "Nouvelle Chimie". 'Avec eduScrum, les étudiants
sont effectivement capables de s'orienter et de se développer en tant qu'être
humain, ce qui donne beaucoup de satisfaction.'
Ellen Reehorst est conceptrice pédagogique et formatrice. Sa devise :
l'éducation qui compte. Sa façon de travailler : énergique et positive.
'L'énergie d'apprentissage qu'eduScrum provoque chez les étudiants et les
enseignants : cela me stupéfie à chaque instant !'
Les étudiants :
La plupart des idées pour améliorer eduScrum proviennent des étudiants eux-mêmes. Nous avons mis
en œuvre leurs idées et leur créativité.
© 2013 équipe eduScrum, tous droits réservés Page 22
La fondation eduScrum et les amis d'eduScrum
La poursuite du développement d'eduScrum est rendue possible avec l'aide de la fondation pour le
développement d'eduScrum composée de Ilja Heitlager (Schuberg Philis), Jacqueline Evers (Xebia) et
Franc Klomp (Tele2) et des amis d'eduScrum.
Nos partenaires sont : Jeff et Arline Sutherland (Scrum Inc.), Schuberg Philis, Xebia, Tele 2,
Prowareness.
Le groupe croissant des ‘amis d'eduScrum’ est : Mark Reijn, l'initiateur (Schuberg Philis), Rini van
Solingen (Prowareness), Arno Delhij (Humanz), Serge Beaumont (Xebia), Henri van den Dam (Tele2),
Tilly van Wijk, Judith Rijnders & Lieneke Koenes (Equipe de direction Ashram College), Maarten Bruns
(Perspectivity), Frank Seller (Seller Avies), Martin Bruggink (TU Delft), Ben Linders (Ben Linders Advies),
Theo Gerrits (Xebia), Jaap Versfelt (stichting LeerKRACHT), Joost Ruland (Chillabs), Jeroen Venneman
(Xebia), …
Pour aller plus loin, visitez notre site :
http://www.eduscrum.nl
© 2013 équipe eduScrum, tous droits réservés Page 23