The History of Scrum

By Victor Hoang · Updated Oct 24, 2026

Picture the accepted view in the mid-1990s. Ken Schwaber's 1995 paper opens with it. The stated philosophy for systems development was that it could be planned, estimated and successfully completed. The paper says this "has proven incorrect in practice." That gap between plan and practice is the problem the people in this story kept trying to fix.

Scrum took its name from a 1986 Harvard Business Review paper by Hirotaka Takeuchi and Ikujiro Nonaka. It compared fast product development to a rugby team. Jeff Sutherland built what he calls the first Scrum at Easel Corporation in 1993. Ken Schwaber and Sutherland first presented it together at the OOPSLA conference in 1995. The two published the first Scrum Guide in 2010.

The throughline is an import that was reshaped on arrival. A way of building cameras, copiers and cars in Japan became a way of building software in Massachusetts, then a framework taught in classrooms, and finally a short document that the authors keep trimming. This article follows that path. For how the framework works today, read what Scrum is; here we tell where it came from.

Timeline at a Glance

The Iterative Roots (1930s-1985)

Short cycles work for decades before anyone calls them Scrum

Start in 1958 with a team in Washington, DC, building software for NASA's Project Mercury. Craig Larman and Victor Basili's history of iterative and incremental development says the team ran very short, half-day iterations, reviewed every change and wrote tests before each small increment. Gerald Weinberg, who worked on the project, recalled in that history that the team thought "waterfalling" a huge project was "rather stupid."

The idea was older than the project. Larman and Basili trace iterative development back to Walter Shewhart's work at Bell Labs in the 1930s, where he proposed a series of short plan-do-study-act cycles for quality improvement, and to W. Edwards Deming, who began promoting those cycles in the 1940s. They add that the 1950s X-15 hypersonic jet project applied iterative methods and that some of its people seeded Mercury. In their words, software's use of the practice "dates as far back as the mid-1950s."

Be careful about what this proves. These are precursors, not Scrum. Nobody in the 1950s used sprints, a backlog or a product owner. What the record shows is that the instinct behind Scrum, build a little, learn, adjust, had decades of practice before it got its name. And Larman and Basili make a point that matters later: some people saw iterative development as the "modern" replacement for waterfall, when its practiced roots went back decades.

What this means for teams today: Scrum is not the first time anyone worked in short loops. If a team treats it as a revolution, it will throw away what these older traditions learned about feedback and testing.

The Rugby Paper (1986-1992)

A Harvard Business Review article lends the name

Now move to Japan, in the late 1970s and early 1980s. At Fuji-Xerox, a team building the FX-3500 copier, introduced in 1978, laid its work out like slices of raw fish on a plate, one overlapping the next. At Honda, the core project team behind the City car (1981) stayed together from start to finish. At Canon, production engineers stepped onto the designers' turf while the Auto Boy camera (1979) was still being designed.

Takeuchi and Nonaka studied these teams and published their findings in the January-February 1986 issue of HBR. Their paper contrasts the traditional sequential "relay race" approach, which they say NASA's phased program planning system exemplified, with a holistic "rugby" approach, in which a team goes the distance as a unit. It names six characteristics: built-in instability, self-organizing project teams, overlapping development phases, "multilearning," subtle control, and organizational transfer of learning. One section is titled "Moving the Scrum Downfield." The paper reports that Fuji-Xerox cut development time from 38 months for an earlier model to 29 months for the FX-3500.

Two details matter for the later story. First, the paper is about product development in firms making copiers, cars, cameras and computers, not a method for software teams. Second, the "scrum" is a rugby image, not a set of roles and meetings.

The leap to software happened a decade later. Schwaber's 1995 paper says the approach was "first observed by Takeuchi and Nonaka" at the companies they studied, and that its authors took the name "after the SCRUM in rugby," describing a tight formation of forwards who bind together when a scrumdown is called. That leap to software is the subject of the next era.

What this means for teams today: The original argument was about handoffs. Where one group passes the baton to the next, problems pile up at the pass. Look at your own handoffs before you look at your meetings.

The Easel Experiment (1993-1999)

Two software practitioners turn a metaphor into sprints and a backlog

Sutherland's own account is short. In a foreword to a 2006 book, he says "I created the first Scrum in 1993 at Easel Corporation" in Burlington, Massachusetts, with a CEO who bet the company on the team. He adds that in 1995 he began working with Schwaber, who formalized the process for wider use. Larman and Basili describe that early Scrum as using time-boxed 30-day iterations and say it took inspiration from Japanese iterative approaches used at firms such as Honda and Canon, from the sashimi approach and from the 1986 paper. Their history places both men at Easel, while Sutherland's foreword dates their joint work from 1995. The accounts differ on that detail.

Schwaber's paper is the first full description. Its abstract calls the development process an "unpredictable, complicated process" and presents Scrum as "an enhancement of the commonly used iterative/incremental object-oriented development cycle." That is the same instinct as the Iterative Roots, restated for object-oriented teams. The paper defines a backlog, a pregame of planning and architecture, development sprints of usually one to four weeks each followed by a review, and a postgame of closure. It also cites James Coplien's study of a Borland project, which it calls the highest productivity C++ project ever documented.

The date needs care. Scrum's own guide says Schwaber and Sutherland "first co-presented Scrum at the OOPSLA Conference in 1995". Sutherland's footnote places Schwaber's paper in a 1997 Springer volume of workshop papers, and Gunther Verheyen's history of how Scrum was defined argues that the paper's content is from 1996. So: presented in 1995, in print by 1997, and described as dating from 1996 by one account.

The 1995 version was also narrower than today's. Schwaber wrote that it was a management methodology for an existing system or production prototype and that totally new development would be addressed later. By 1999, according to Verheyen's summary, a pattern-language article by Mike Beedle, Martine Devos, Yonat Sharon, Schwaber and Sutherland described a daily meeting of 15 minutes, a sprint of about 30 days and a prioritized backlog, and introduced the Scrum Master as a team leader role.

What this means for teams today: The first Scrum was a fix for one team's problem, written down after it worked. Treat any framework the same way: start from your problem, not from the ceremony list.

After Snowbird (2000-2009)

The agile movement spreads Scrum, then classrooms and rival camps follow

On February 11-13, 2001, seventeen people met at the Lodge at Snowbird, a ski resort in Utah's Wasatch mountains. The signatories included Schwaber, Sutherland and Mike Beedle, and the document they wrote values "Responding to change over following a plan." Schwaber later wrote that he and Sutherland had been using Scrum for ten years before the meeting, and that the manifesto, his first book and modern development environments helped Scrum spread "like wildfire" in the early 2000s. Our guide to the Agile Manifesto covers what it says, and the history of the Agile Manifesto tells how the Snowbird meeting came about; here the point is that Scrum rode the wave.

Success created a new problem: the label spread faster than the understanding. In a 2010 letter, Schwaber described flying home from a conference with Martin Fowler, dismayed that so many customers had not understood Agile and Scrum, and deciding that training and certification were needed. He built a two-day ScrumMaster course, the first of which ran at ObjectMentor in Chicago in 2002. He certified attendees as just that, attendees, and listed their names on his website.

The Scrum Alliance came out of this period. Its own site says it was founded in 2001; Verheyen's timeline lists it as 2002, with Schwaber, Mike Cohn and Esther Derby. Schwaber's first book on Scrum, written with Beedle, also appeared in 2002, and according to Verheyen it formally named the Product Owner and the Daily Scrum.

Scaling was already being tried inside one company. In the foreword quoted earlier, Sutherland describes PatientKeeper running a 15-minute daily "Scrum of Scrums" and managing 45 software releases a year, with a weekly MetaScrum meeting where the Product Owner and stakeholders reset priorities.

By 2009 Schwaber saw a different problem. He wrote that more organizations were using agile than waterfall, but fewer than half of the Scrum users were building in incremental iterations, which he called the heartbeat of Scrum. Fowler had written of "Flaccid Scrum," where teams used the vocabulary without producing a potentially shippable increment in a Sprint. Schwaber decided he needed a new organization, and Scrum.org was founded by him and Alex Armstrong. He wrote that his earlier attempt to build the program elsewhere had not worked.

What this means for teams today: Vocabulary is not practice. If your team holds the meetings but cannot show working output every Sprint, you are in the situation Schwaber described in 2009.

The Guide Years (2010-2019)

Two authors write the definition down, then keep trimming it

The Scrum Guide's own history page says its authors "wrote the first version of the Scrum Guide in 2010" to help people worldwide understand Scrum. According to Verheyen, Schwaber had made an earlier document called the ScrumGuide in May 2009, and the 2010 version was published with Sutherland as co-author.

The revision history shows the direction of change. In 2011 the guide dropped the idea that the team commits to a Sprint's work in favor of a forecast, stopped requiring a burn-down chart, and changed "prioritized" to "ordered" for the Product Backlog. In 2013 Sprint Planning became one event with a Sprint Goal, backlog grooming became refinement, and the Daily Scrum questions were reformulated to emphasize the team over the individual. In 2016 it added the Scrum Values: commitment, courage, focus, openness and respect. In 2017 it added a section on the uses of Scrum, saying it had been used for software, hardware, networks, schools, government and marketing.

Notice the direction. The guide describes its own changes as "small, functional updates," and several of them loosen a rule instead of adding one. Verheyen observes that many people look for exact instructions in Scrum's definition, which the definition intentionally leaves out. That tension runs through the whole history.

What this means for teams today: The Scrum Guide changed on purpose. If a coach quotes you a rule from 2011, check whether the current guide still says it. Our guides on sprint planning and the split between the Scrum Master and Product Owner reflect today's wording.

The Self-Managing Turn (2020-present)

One Scrum Team, one Product Goal, and a shorter guide

The November 2020 Scrum Guide is the latest version. According to the revision notes, it aimed to bring Scrum back to being a "minimally sufficient framework" by removing or softening prescriptive language. It removed the Daily Scrum questions, introduced a Product Goal, gave the Sprint Backlog its Sprint Goal and the Increment its Definition of Done as commitments, and replaced the self-organizing Development Team with a single self-managing Scrum Team made of three accountabilities: Developers, Product Owner and Scrum Master. Sprint Planning gained a third topic, "Why." The guide became shorter than 13 pages and dropped remaining references to IT-specific work.

The guide now describes Scrum as developed and sustained for "30-plus years" by Sutherland and Schwaber. It sets out five events, the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective, and defines Scrum as a lightweight framework for adaptive solutions to complex problems.

Alongside the single-team guide, the two organizations around Scrum's creators each publish a way to coordinate many teams. Scrum.org's Nexus Guide describes a framework that minimally extends Scrum so multiple teams can work from one Product Backlog. Sutherland's Scrum@Scale guide describes a way to coordinate an ecosystem of teams with what it calls "minimum viable bureaucracy." For where teams mix Scrum with other approaches, see our history of hybrid project management and our guide to Scrum versus Kanban.

What this means for teams today: The newest version asks the team to own its choices, with a goal at each level. If your Scrum depends on a manager assigning tasks inside the Sprint, you are working from an older picture.

Key People

Key Facts

Key Facts: Scrum History

• The 1986 HBR paper by Takeuchi and Nonaka is the source of the rugby analogy, in the contrast between "relay race" and "rugby" product development.
• Sutherland says he created the first Scrum in 1993 at Easel Corporation in Burlington, Massachusetts.
• Schwaber and Sutherland first co-presented Scrum at OOPSLA in 1995.
• Seventeen people wrote the Agile Manifesto on February 11-13, 2001, at Snowbird, Utah.
• The first Scrum Guide was written in 2010; the current version dates from November 2020.

The Pattern Behind the History

We call this the Borrowed Frame pattern. It is our reading of the timeline, not a research result.

1. A metaphor crosses a border. Rugby moved from sport to product development, then from product development to software.
2. A local fix comes first. Easel's team solved its own delivery problem before anyone wrote the rules down.
3. The label outruns the practice. After 2001 the vocabulary spread faster than working increments, which is the "Flaccid Scrum" complaint.
4. Training and certification arrive to close the gap. A course in 2002 and a second organization in 2009 tried to protect the meaning.
5. The text shrinks as it matures. From long descriptions in the 1990s to a guide of fewer than 13 pages in 2020.

What It Teaches Teams Today

• Start from a problem. Every version of Scrum began as a fix for something that hurt: handoffs, late feedback, signed-off plans that no longer matched the market.
• Judge Scrum by working output. The test Schwaber used in 2009 was whether a team could produce a usable increment in a Sprint.
• Read the current Scrum Guide, not a rule someone remembers from 2011. The authors have deliberately softened or removed rules over the years.
• Keep Scrum's roots in view. It sits in a line that runs from plan-do-study-act cycles through the rugby paper to modern iterative delivery, and our evolution of project management methodologies places it among the other methods.
• Compare it with its neighbors honestly. The history of Kanban and the history of the waterfall model show what the other two big traditions solved, and lean project management covers the manufacturing thinking that sits behind both.

For the wider story, read the history of project management.

Scrum's record shows an idea that kept changing hands and kept getting simpler. The metaphor came from rugby, the first practice from a Massachusetts software firm, and the current text from two authors who keep trimming what they wrote.