The Evolution of Scrum: From the 1986 HBR Paper to the 2020 Guide and the 2025 Expansion Pack

Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland). On 8 November 2026, scrumguides.org and its revision history page were checked again: the current official version is still 2020; the latest version of the Scrum Guide Expansion Pack is v2026.1 (18 January 2026), and it does not replace the official Guide.

Guess First

A Developer who has just joined Bookstore asks Kerem three questions. First: "Where does the word Scrum come from, was it born in software?" Second: "How many times has the Scrum Guide changed since 2010, and what was the biggest change?" Third: "I heard a new Scrum Guide came out in 2025, are we going to use that now?"

Write down your answer to each. The answer to the third is especially important; there is serious confusion about it in the field, and it becomes clear by the end of the post.

1986: Rugby and the Relay Race

The word Scrum entered the software world through a business article. In the January 1986 issue of the Harvard Business Review (HBR), Hirotaka Takeuchi and Ikujiro Nonaka examined how Japanese and American companies developed new products in their article "The New New Product Development Game". Drawing on examples from companies such as Fuji-Xerox, Canon, Honda and NEC (Nippon Electric Company), they compared two approaches. The first is the relay race: each specialist group finishes its phase and hands the work to the next. The second is rugby: the team moves forward together, passing the ball back and forth on the field.

The article lists six characteristics of the rugby approach: deliberately giving the team a vague but ambitious goal (built-in instability), self-organizing project teams, overlapping development phases, multilearning, subtle control, and organizational transfer of learning. Almost every idea in present-day Scrum is on this list as a seed: the cross-functional, self-managing team, phases overlapping within the Sprint, the learning loop of the Retrospective.

The article did not propose a software process; it was an observation about manufactured and hardware products. But it is the first text to use the word "scrum" for a way of working as a team.

1993–2001: Easel, OOPSLA and the Manifesto

Jeff Sutherland applied the article's ideas to a software team at Easel Corporation in 1993. Ken Schwaber was working on a similar approach at his own company. The two first presented Scrum together at the OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) conference in 1995. The Guide's own history note describes this presentation as documenting what they had learned over the previous few years and making the first formal definition of Scrum public, and it names Individual Inc., Newspage, Fidelity Investments and IDX (now part of General Electric) as the first places Scrum was tried.

In 2001, Schwaber and Sutherland were among the 17 people who signed the Agile Manifesto at Snowbird. The story of the Manifesto and its four values is in the Agile Mindset series post "The Agile Manifesto: What Happened at Snowbird in 2001 and What the Four Values Really Say". After that Scrum became the most widespread Agile framework; but for a decade it had no single official definition. Books, trainings and organizations each described Scrum in their own way.

2010–2017: The Revisions of the Scrum Guide

Schwaber and Sutherland published the first Scrum Guide in 2010. Since then, according to the revision history on scrumguides.org, the Guide has evolved through small, functional updates. The most discussed changes in the revisions before 2020:

This table answers many of the "whys" in the earlier posts of the series. Why the Product Backlog is ordered (03), why commit turned into forecast (04), where the three Daily Scrum questions came from and went (05), and why undone work disappeared (06) are all traces of these revisions.

2020: Fewer Rules, a Wider Audience

The November 2020 version is the most extensive revision. According to the revision notes, its main direction is bringing the Guide, which had become too prescriptive over the years, back to being a "minimally sufficient" framework. Compared with 2017:

The last row is the least noticed but most strategic change. The 2017 version had added a section on uses of Scrum outside software; the 2020 version went a step further and cleaned IT connotations out of the text. The authors' note in the introduction that they use the word "developers" to simplify, not to exclude, is part of this too. Scrum is now a text that a marketing team, a research group or a school can read.

2025: The Scrum Guide Expansion Pack

In June 2025, Jeff Sutherland, Ralph Jocham and John Coleman published the Scrum Guide Expansion Pack at scrumexpansion.org. The versions listed on the site are v2025.6 and, as of November 2026, the latest, v2026.1, dated 18 January 2026. The text is licensed under Creative Commons BY-SA 4.0 and describes itself as a companion to the 2020 Scrum Guide. Ken Schwaber is not among the authors.

The Expansion Pack reaches into areas the 2020 Guide deliberately left out. Highlights:

• Supporting theory sections such as complexity theory, emergence, the OODA (Observe, Orient, Decide, Act) loop, product thinking, systems thinking and leadership.
• Four "Scrum roles": Product Owner, Product Developer, Scrum Master and Stakeholder; plus a type of stakeholder called Supporter. A deliberate departure from the 2020 Guide's choice of "accountability" over "role".
• An AI (Artificial Intelligence) section: what AI can contribute to a team, from refinement to decision support, while keeping human accountability for every outcome (human in the loop).
• Defining the Product as an artifact, and two new commitments: the Definition of Outcome Done, which proves value was realized, and the Definition of Output Done, the Increment's quality standard.

The text marks the places where it departs from the 2020 Guide itself and explicitly calls them "departures". On the Scrum.org side, a forum answer in August 2025 described the Expansion Pack, like Nexus, as an optional addition built on top of Scrum that does not change Scrum; the same thread also includes practitioners criticizing the Outcome/Output Done split and the AI section.

Why It Is Not a "New Scrum Guide"

The answer to the third question: no, Bookstore keeps using the Scrum Guide 2020. The reasons are concrete. The official definition of Scrum is at scrumguides.org and is, as the Guide itself says, the text Schwaber and Sutherland stand behind together; on 8 November 2026 the latest version on the revision history page is still 2020. The Expansion Pack carries the signature of only one of the two founders, describes itself as a companion, and marks the places where it deliberately departs from the 2020 Guide.

That does not make the Expansion Pack worthless. Linking the Product Goal to outcomes, describing stakeholders in detail and the questions about AI's place in a team are topics Bookstore discusses too. But two things should be kept in mind when reading it: most of its content enters areas we saw as "what the Guide does not say" in earlier posts of the series, and choosing its suggestions is the team's decision; the definition of Scrum has not changed.

One Paragraph on Scaling: Nexus

The Guide describes the team as "typically 10 or fewer people" and, for growing teams, only suggests several Scrum Teams sharing the same Product Goal, Product Backlog and Product Owner for the same product. How to do that is defined by the Nexus Guide from Ken Schwaber and Scrum.org (latest version January 2021): a Nexus of roughly three to nine Scrum Teams, a Nexus Integration Team accountable for producing an integrated Increment every Sprint, and additional events such as Nexus Sprint Planning and the Nexus Daily Scrum. Nexus, like the Expansion Pack, is an addition built on top of Scrum; the Agile Mindset series post "The Evolution of Agile: From the Manifesto to Modern Agile and the Scaling Debate" discusses scaling frameworks in a wider frame.

In Production: What to Watch

Which Scrum a team practices shows in its training materials and internal documents. At Bookstore an internal wiki page still listed 2017's "Development Team" and the three Daily Scrum questions as "Scrum rules"; newcomers learned Scrum from there. Kerem updated the page to the 2020 Guide and wrote the source and date at the top. A simple rule: every internal Scrum document should state which Guide version it is based on.

How often the Guide changes is data too: six versions from 2010 to 2020, none from 2020 to November 2026. When the next official revision comes, what Bookstore will do is clear: read the revision notes, compare them with its own Definition of Done, working agreements and internal documents, and discuss the differences in a Retrospective.

Common Pitfalls

Mistaking the Expansion Pack for the new Scrum Guide. When it enters a certification exam, a team discussion or a corporate standard as "the 2025 Scrum Guide", the suggestions of an addition are taken as the basis instead of the definition of Scrum.

Carrying over rules from old Guide versions. "Development Team", "the three questions", "commit" and the requirement of "at least one Retrospective action in the Sprint Backlog" are still taught in many training materials as if they were 2020 rules.

Using history as an authority instead of a reason. "That's what the 1986 article says" does not justify a practice; the article is the source of today's Scrum, not its definition.

A Small Experiment

★☆☆ Open your team's Scrum training materials or internal wiki page and look for three things that changed in 2020: "Development Team", the three Daily Scrum questions and the Product Goal. Which are outdated, which are current?

★★☆ Read the revision history page on scrumguides.org and find which revision brought one of your team's current practices into the Guide or took it out. For example, how does your velocity tracking relate to the Guide dropping the mandatory burndown in 2011?

★★★ Read the Definition of Outcome Done section of the Expansion Pack and write an outcome measure for your own Product Goal. Then consider where it fits in the 2020 Guide: is it part of the Product Goal, data discussed at the Sprint Review, or a practice outside the Guide?

The series ends here. We have seen every part of the Scrum Guide 2020, how it is applied in the field, its metrics, engineering practices and anti-patterns. The next step is looking at your team's own Scrum with this eye: which part serves its purpose, and which one stands there only as form? If you want to go deeper on the flow side, the Kanban series post "Scrumban and the Kanban Guide for Scrum Teams: Adding Flow to Scrum" is the natural continuation of this series.