Scrum at a Glance

What Scrum is

Scrum is a lightweight framework that helps people, teams and organizations create value through adaptive solutions for complex problems. "Complex" is the key word: Scrum is meant for work where you cannot know everything in advance, such as building a new product, where the requirements, the technology and the people all bring surprises. For simple, repeatable work a checklist is enough; see Choosing an Approach for how to tell the difference.

In a nutshell, the Scrum Guide describes it like this: a Scrum Master fosters an environment where a Product Owner orders the work for a complex problem into a Product Backlog; the Scrum Team turns a selection of that work into an Increment of value during a Sprint; the team and its stakeholders inspect the results and adjust for the next Sprint; and then it repeats.

Scrum is a framework, not a method or a process. The Scrum Guide calls it "purposefully incomplete": it only defines the parts needed to implement Scrum theory, and it deliberately says nothing about how to write requirements, estimate, test or deploy. Teams fill those gaps with practices of their own choice, and Scrum makes visible whether those practices work.

The Scrum Guide

The Scrum Guide is the official definition of Scrum, written and maintained by its creators, Ken Schwaber and Jeff Sutherland. They first presented Scrum together at the OOPSLA conference in 1995, wrote the first Scrum Guide in 2010, and have updated it several times since. The current edition is the Scrum Guide of November 2020, published at scrumguides.org. It is short and free, and it is licensed under Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0), which is why you will find it quoted and translated everywhere.

The guide is also strict about what counts as Scrum. Its end note says the framework is "immutable": you can use parts of it, "the result is not Scrum". That does not make partial use wrong; it just means you should not call it Scrum and then blame Scrum for the result.

The framework in one picture

Scrum has three parts that interlock: the Scrum Team with three accountabilities, five events, and three artifacts, each with a commitment. The picture below shows how work flows through them during one Sprint.

Empiricism and lean thinking

The Scrum Guide puts it in one sentence: "Scrum is founded on empiricism and lean thinking."

Empiricism means that knowledge comes from experience, and that you make decisions based on what you observe rather than on what you predicted. In complex work, a detailed plan made in advance is mostly a guess; a working piece of product in front of real users is a fact. Scrum therefore works in short cycles. Each Sprint produces something you can inspect, and what you learn steers the next Sprint. The guide calls this an iterative, incremental approach "to optimize predictability and to control risk": if you are wrong, you find out after weeks, not after a year.

Lean thinking, in the guide's words, "reduces waste and focuses on the essentials". It comes from manufacturing, where Toyota showed that cutting everything that does not add value for the customer makes work faster and better at the same time. In Scrum you see it in the small batches of work, the single ordered backlog, and the habit of stopping work that no longer serves the goal. See Lean Thinking for the full story.

The three pillars

Empiricism only works when three things are in place. The Scrum Guide calls them the pillars of Scrum, and every event exists to serve them. Here they are, with examples from the Portal team at Kestrel Energy, which builds the customer portal and app: Product Owner Isabel Santos, Scrum Master Lars de Boer, and the Developers Ravi Kumar, Sofia Lindqvist, Kwame Asante, Priya Shah and Bram Peeters.

Transparency

Transparency means that the process and the work are visible to the people doing the work and to the people receiving it. Important decisions in Scrum are based on the state of the three artifacts, so if those artifacts lie, decisions go wrong. As the guide puts it: "Transparency enables inspection."

At Kestrel: Kwame marks the new payment-plan screen as done, but the load test has not run yet. On the board it looks finished; in reality, a risk is hidden. Because the team has a shared Definition of Done that includes the load test, Sofia notices and the item goes back to "in progress". Everyone now sees the real state.

Inspection

Inspection means looking at the artifacts and the progress toward the goals frequently and diligently, to spot problems and unwanted variances early. The five events give inspection a regular rhythm. "Inspection enables adaptation", and inspection without transparency is misleading.

At Kestrel: in the Daily Scrum, Ravi sees that the login change everyone depends on is two days behind. In the Sprint Review, the customer service team watches a real customer use the new app screen and notices that customers cannot find the meter-reading button.

Adaptation

Adaptation means adjusting the process or the product as soon as possible when inspection shows it has drifted outside acceptable limits. The guide expects a Scrum Team to adapt "the moment it learns anything new", and notes that adaptation is hard when people are not empowered or self-managing: a team that needs permission for every change cannot adapt quickly.

At Kestrel: after the Daily Scrum, Priya and Bram drop their own tasks for a day to help Ravi with the login change. After the Sprint Review, Isabel moves the meter-reading redesign to the top of the Product Backlog. In the Retrospective, the team adds the load test to its pipeline so it can no longer be forgotten.

The five Scrum values

The pillars describe the mechanics; the values describe the behavior that makes the mechanics work. The guide says successful use of Scrum depends on people becoming more proficient in living five Scrum values: commitment, focus, openness, respect and courage.

Why do the values matter? Because the pillars depend on trust. People only make problems transparent when they are not punished for it (openness, respect), and they only adapt when they dare to change course (courage). The guide says that when the values are lived, the pillars "come to life building trust". When they are not, Scrum turns into a set of meetings in which everyone reports green.

Timeboxes

A timebox is a fixed maximum amount of time for an event or activity. When the time is up, the event ends, whether or not everything was discussed. Timeboxes keep meetings short, force the team to focus on what matters most, and make the rhythm of the work predictable.

For shorter Sprints, the guide says these events are "usually shorter". A timebox is a maximum, not a target: a Sprint Review that achieves its purpose in one hour does not need to fill four. The details per event are on Scrum Events.

What changed in 2020

Much training material, and many colleagues, still use the words of the 2017 edition. The November 2020 guide changed the vocabulary and removed detail. The main differences:

• Product Goal. New: a long-term objective for the Scrum Team, part of the Product Backlog.
• Commitments. Each artifact now has one: the Product Goal, the Sprint Goal and the Definition of Done.
• Accountabilities instead of roles. The guide speaks of three accountabilities: the Developers, the Product Owner and the Scrum Master.
• Developers instead of a Development Team. The separate "Development Team" inside the Scrum Team is gone. There is one Scrum Team, with no sub-teams or hierarchies.
• Self-managing instead of self-organizing. The whole Scrum Team, not only the Developers, is self-managing: it internally decides who does what, when, and how. The authors' revision notes describe the shift as going from choosing who and how to choosing who, how and what to work on.
• "True leaders who serve". This phrase replaced "servant-leader" in the description of the Scrum Master.
• A "why" in Sprint Planning. Planning now starts with why the Sprint is valuable, before what and how.
• Less prescriptive. Details such as the three example questions for the Daily Scrum were removed, and the language became less specific to IT, so that Scrum reads well for any complex work.

Beyond the Scrum Guide

Because Scrum is purposefully incomplete, almost every team adds practices: user stories, story points, task boards, burn-down charts, refinement sessions, working agreements. These can be very useful, but they are not Scrum. In this section, practices that the guide does not prescribe are always marked as such.