Foundations

Scrum in brief: origins and framework

Scrum grew out of an observation made in Japan in the 1980s, took shape in a software team in 1993, and today fits into a free guide of about fifteen pages. This article traces that history, then presents the framework as the 2020 edition of the Scrum Guide defines it: one team, three accountabilities, five events and three artifacts.

A scrum rather than a relay race

Think of a relay race. The first runner does a lap of the track, hands over the baton and stops, and the next one takes over. Many organizations design their products this way: marketing writes a specification and hands it to the design office, which passes drawings to manufacturing, which finally delivers the product to the sales staff. Each department does its part, and nobody follows the product from start to finish.

Early in 1986, two Japanese researchers, Hirotaka Takeuchi and Ikujiro Nonaka, published an article in the Harvard Business Review entitled "The New New Product Development Game". They studied companies that had designed new products faster than their competitors, for example Fuji-Xerox with a copier, Canon with a camera and Honda with a small car, the City. In these companies, a team that brings several professions together moves forward as one from beginning to end, and the phases of the project overlap instead of following one another. The authors compared this way of working to rugby, where the team moves up the field passing the ball back and forth, and they used the word scrum.

Their article describes six characteristics of these teams: built-in instability, created by top management setting a very ambitious goal, self-organizing project teams, overlapping development phases, learning that cuts across professions and levels, subtle control, and the transfer of what has been learned to the rest of the company. Takeuchi and Nonaka were writing about industrial products such as copiers, cameras and cars. Their article does not deal with software development, and the word "scrum" does not yet name a working framework.

From the article to the framework

In 1993, Jeff Sutherland was working at Easel Corporation, an American software company. With Jeff McKenna and John Scumniotales, he organized a team along the lines of Takeuchi and Nonaka's ideas and borrowed the word "scrum". At around the same time, Ken Schwaber was trying out a similar approach in his own company, with Mike Smith and Chris Martin. Schwaber and Sutherland presented Scrum together for the first time in 1995, at the OOPSLA conference, held that year in Austin, Texas. The Scrum Guide recalls these beginnings in its acknowledgments.

In February 2001, Schwaber, Sutherland and Mike Beedle were among the seventeen signatories of the Agile Manifesto. The same year, Schwaber and Beedle published Agile Software Development with Scrum, the first book devoted to Scrum. The first version of the Scrum Guide dates from 2010. Its two authors revised it in 2011, 2013, 2016, 2017 and 2020. The text is free and published under a Creative Commons license (CC BY-SA 4.0). It serves as the official definition, and it is the text to go back to when two people disagree about what Scrum requires.

Scrum has other sources besides the 1986 article. The authors of A Scrum Book (2019), Sutherland among them, connect it to the Toyota Production System, and Sutherland has often named James Coplien's work on organizations among the influences on the first Scrum. The article on Scrum's patterns returns to this lineage.

What the 2020 Scrum Guide says

The Guide defines Scrum as a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. A problem is complex, in this sense, when you cannot know its solution in advance and have to try things in order to learn. Designing a new product or a new service is a good example.

The framework rests on empiricism, that is, on the idea that knowledge comes from experience and that decisions are made on the basis of what is observed. It relies on three "pillars", transparency, inspection and adaptation, which the article on empiricism explains in detail. It also asks those who use it to live five values: commitment, focus, openness, respect and courage. The Guide states that Scrum is deliberately incomplete: it sets out the necessary minimum and leaves each team to choose its own techniques.

One team and three accountabilities

The basic unit is the Scrum Team, a small team, typically of ten people or fewer, with no sub-teams and no internal hierarchy. It brings together all the skills needed to produce something useful in each cycle, and it decides for itself who does what, when and how. The Guide distinguishes three accountabilities within it.

The Product Owner is accountable for the value of the product. They keep the ordered list of what remains to be done up to date. The Guide insists that this is one person, not a committee.
The Developers are the people who build the product, whatever their trade. The word does not refer only to programmers.
The Scrum Master is accountable for Scrum being properly understood and for the team's effectiveness. They help the team improve its practices and make sure that the impediments it runs into are removed.

Five events

The work is divided into Sprints, fixed-length periods of one month or less that follow one another without a break. Each Sprint contains the four other events. The durations in the table are the maximums for a one-month Sprint. They are usually shorter when the Sprint is shorter, except for the Daily Scrum, which always lasts fifteen minutes.

Event	What it is for	Maximum length
Sprint	Turning ideas into a usable result and making progress toward the Product Goal	One month
Sprint Planning	Deciding why this Sprint is valuable, what can be done in it and how the work will be done	8 hours
Daily Scrum	Letting the Developers check progress toward the Sprint Goal and adjust the plan for the day	15 minutes, every day
Sprint Review	Examining the outcome of the Sprint with the stakeholders and deciding what comes next	4 hours
Sprint Retrospective	Looking for ways to improve the quality of the work and the team's effectiveness	3 hours

Three artifacts and their commitments

An artifact is an object that makes the work visible. Since 2020, each one has been paired with a "commitment", that is, a reference point against which progress can be measured.

Artifact	What it is	Associated commitment
Product Backlog	The ordered list of what is needed to improve the product, the single source of the team's work	Product Goal: the future state of the product that the team is aiming for
Sprint Backlog	The Sprint Goal, the items chosen for this Sprint and the Developers' plan for delivering them	Sprint Goal
Increment	A concrete, usable step toward the Product Goal, added to the previous ones	Definition of Done: the description of what a piece of work must satisfy to be called "done"

Books delivered to the door. A municipal library wants to set up a book delivery service for elderly people who no longer get out. Five staff members form the team and choose two-week Sprints. Claire, who runs the adult section, takes the role of Product Owner: she knows the patrons and answers to the town council for the usefulness of the service. Her Product Backlog begins with "serve the first ten readers in a single neighborhood". The large-print catalog and registration by telephone come later. At Sprint Planning, the team adopts this goal for the first Sprint, and the four staff members who will do the work prepare their plan: choosing the readers with the town's social services office, putting together the bags of books and organizing the delivery route. Every morning, they meet for a quarter of an hour in front of their board to adjust this plan. After two weeks, ten readers have actually received their books, and that result is the Increment. At the Sprint Review, two readers and the deputy mayor for culture give their views, and the team learns that the Monday morning slot suits almost nobody. Claire reorders her Product Backlog accordingly. The team ends with its Sprint Retrospective and decides to prepare the bags the day before the route. Bruno, one of the four staff members, has had Scrum training and acts as Scrum Master on top of his own work. He makes sure these meetings take place and stay useful.

What the 2020 edition changed

If you read books or articles written before 2020, you will find slightly different vocabulary. The 2020 edition shortened the text and removed terms specific to software. It speaks of "Developers" where earlier editions spoke of a "Development Team", so that there is no longer a team within the team. It introduces the Product Goal and attaches a commitment to each artifact. It calls the team self-managing rather than self-organizing. It adds the question of "why" to Sprint Planning, and it drops the three questions previously suggested for the Daily Scrum.

These differences matter when reading this site. A Scrum Book, on which it draws, came out in 2019: it speaks of the "Development Team", writes "ScrumMaster" as one word and counts three "roles" where the 2020 Guide speaks of accountabilities. The articles point out these gaps whenever they have a practical consequence.

What the Guide does not say

Many practices people associate with Scrum do not appear in the Guide. User stories, story points, velocity and the column board are not mentioned, and progress charts are cited only as an example. These are complementary techniques, often useful, but a team can apply Scrum without them.

The Guide itself says that describing these practices is beyond its purpose, because they depend on context, and it refers readers to other sources. A Scrum Book is one of them. Its authors compare the Guide to the rulebook of chess: you need to know it, but reading it will not make you a good player. Their patterns describe what the rules leave out, that is, the problem each element of Scrum tries to solve and the way teams have gone about it.

All the tools, without the framework. A team of six is developing the appointment booking app for a network of physiotherapy practices. It has a column board, user stories estimated in points and a stand-up meeting every morning, and it says it is "doing Scrum". Yet at the end of every three-week period, nothing is usable: features are "almost finished" and are waiting for a test campaign planned for the end of the quarter. No physiotherapist has seen the app since the project began, and priorities are set by a committee of four directors that meets once a month. Going back to the Guide, what is missing here is a finished Increment in every Sprint, a Sprint Review with the people concerned and a single Product Owner. The team has adopted techniques the Guide does not ask for and left out what it does ask for.

Limits and pitfalls

Scrum is designed for complex work, whose solution is discovered along the way. For repetitive, well-understood work, such as processing files that are all alike, cycles with a goal and a review add little, and other approaches are a better fit (see the Lean corpus, in French).

The Guide states that the framework is "immutable" and that implementing only parts of it is not Scrum. This firmness protects the definition, but it also encourages a checklist reading, in which people verify that the five events are present without asking whether they serve any purpose. The article on the spirit of the game is devoted to this risk.

Finally, history and evidence need to be kept apart. The story of the origins is told mostly by the founders themselves. The spectacular productivity gains sometimes claimed, notably by Jeff Sutherland, have not been established by independent studies. The article Criticism and the state of the evidence reviews what is known.