Scrum in education: classrooms, projects and course design

A class project has a goal, a deadline and a group of people who must work together, with someone telling them at the end whether it was good. Most of the learning is in the working together, and most of the feedback arrives too late to help. Scrum offers a different shape: short cycles, visible work, regular feedback and a deliberate look back. Teachers and trainers use it for exactly these reasons.

Where it fits

Research on agile learning describes it as the transfer of agile principles to learning processes: incremental steps and an iterative approach that alternates between phases of learning and doing, with the teacher taking the role of a learning attendant or supporter more than a lecturer. The same description notes that Scrum's ideas, work broken into time-boxed iterations with clear goals and regular feedback loops, daily short meetings and a reflection at the end, can be adapted to the needs of dynamic, workplace-integrated competence development.

The Scrum Guide's own domain statement applies: Scrum is used in many domains with essentially complex work, and the word Developers includes anyone who does the work. A group of students building a game, a research poster or a community project is a team doing complex work.

Education uses Scrum in three ways: as a method for running a project course, as a subject taught to learn project work, and as a design approach for developing the course itself.

Mapping the framework to a classroom

The teacher's role is the most delicate. The Guide's picture of a Scrum Master who serves, coaches and does not direct applies. The teacher coaches the groups in self-management, as the Guide says, and also holds the course's learning goals. Where the teacher also grades, the roles must be separated clearly.

Why it helps learning

Early feedback. A Review every week or two tells students whether they are on track while there is still time to change.

Reflection built in. The Retrospective teaches students to examine their own process, which is a transferable skill.

Shared responsibility. The team owns the plan, which develops planning and collaboration.

Visible work. A board makes progress, or its absence, obvious to the group and to the teacher.

Real constraints. A fixed Sprint teaches the hard lesson that time is fixed and scope must flex.

Learning from failure. A Sprint that goes wrong is information, not a final grade.

A worked example

This is an illustrative twelve-week course in which teams of five build a web app for a local charity. The teacher plays the Product Owner for the charity's needs with help from a real charity contact. A teaching assistant acts as coach.

Week one. Teams meet the client, write a product goal and a first backlog. They agree a Definition of Done that includes working code, a short test and a note of what they learned.

Weeks two to ten. Five two-week Sprints. Each starts with planning in which the team chooses a Sprint Goal, such as "a volunteer can sign up for a shift". A student acts as Scrum Master for each Sprint, rotating. The groups hold a ten-minute stand-up at each class. A board is visible on the shared screen.

Sprint Reviews. Each Sprint ends with the groups showing the working app to the charity contact and to another group. The contact says what is useful. Another group asks questions. After Sprint two, one group realises its sign-up form is confusing, because volunteers misread the dates, and changes it the next day.

Retrospectives. Each group spends twenty minutes on one thing to change. One group discovers that a dominant member decides everything and agrees to rotate decisions.

Weeks eleven and twelve. A final Review to the charity, a short written reflection by each student on their contribution and their learning, and a team portfolio.

Assessment looks at several things: the final Increment's quality against the Definition of Done, individual reflections, peer feedback and the teacher's observation of the process. The charity gets a working tool, and students leave having practised planning, feedback and teamwork, not only coding.

Cautions

• Grades distort the events. If everything is graded, students will hide problems in the Retrospective. Make some activities ungraded and grade the learning shown over time.
• Teacher as boss. If the teacher assigns tasks, the team is not self-managing. Coach and step back.
• Fake Product Owners. A client with no real need or authority makes decisions arbitrary. Use real stakeholders where possible.
• Unequal contribution. Visible boards and peer feedback help, as does a rule that everyone shows their own work at the Review.
• Too much ceremony. A group of three students on a two-week task needs a light version.
• Skipping the retrospective. It is where most of the learning about teamwork sits.
• Assuming student teams have software. The framework works for any project: a research poster, a play, a product design.

Teaching Scrum itself

Where the aim is to teach Scrum, short simulations with a physical product, such as building from paper or blocks in timed Sprints, give students the experience of planning, delivering and reflecting in an hour. They are most useful if followed by discussion linking them to the Guide's events. A longer project then applies what was learned. The simulator on this site gives a similar experience of making decisions in each role over several days.

How to practise it

If you teach or train, run one short project with two Sprints and a Review in front of someone outside the group, and see what the Retrospective reveals. In the simulator you act in a role over several days and see the consequences, which is the same cycle of doing and reflecting.