What Is Scrum? Empiricism, Lean Thinking and the Problem Scrum Solves

Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. The Scrum Guide Expansion Pack published in 2025 does not replace the official Guide; the last post of the series covers it separately.

Guess First

The Bookstore team has gathered for a new piece of work: letting customers open a return request on the site itself instead of emailing support. The team has five Developers (Ayşe and Emre on the backend, Zeynep on Angular, Can on the pipeline and infrastructure, Deniz on test automation), a Product Owner (Selin) and a Scrum Master (Kerem). The company has announced "we do Scrum now", and the first Sprint starts on Monday.

Kerem reads four sentences to the team and asks which of them are in the Scrum Guide: "We will measure our velocity every Sprint", "Everyone will answer three questions in the Daily Scrum", "Product Backlog items will be written as user stories", "A Sprint lasts one month or less". How many do you think are in the Guide? The answer comes shortly, not at the end; but write your guess down first.

Scrum Is a Framework, Not a Methodology

The Guide defines Scrum in one sentence: a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. Two words in that definition do a lot of work. "Framework" says Scrum is not a methodology that tells you what to do step by step; the Guide describes itself as purposefully incomplete and defines only the parts required to implement Scrum theory. "Lightweight" says those parts are few: three accountabilities, five events, three artifacts and one commitment attached to each artifact. That is all.

The Guide's own summary is a four-step loop as well. A Scrum Master fosters an environment in which a Product Owner orders the work for a complex problem into a Product Backlog, the Scrum Team turns a selection of that work into a valuable Increment during a Sprint, and the Scrum Team and its stakeholders inspect the results and adjust for the next Sprint. Then repeat.

The practical consequence of being a framework is that the Guide stays silent on branch strategy, testing approach, estimation technique, board columns and meeting formats. The team chooses those. In the Guide's own terms, Scrum wraps around existing practices or renders them unnecessary; its real contribution is making visible how well the current management and work techniques actually work. In other words, Scrum does not hand you a good engineering process; it shows you how bad a bad process is, every two weeks.

Empiricism: The Three Pillars

The Guide founds Scrum on two things: empiricism and lean thinking. Empiricism says knowledge comes from experience and decisions should be based on what is observed. In complex work, where what to build and how to build it are not fully known up front, moving in short cycles and looking at reality in each cycle is less risky than making a detailed plan and following it. The approach has three pillars:

The three are chained together. The Guide says transparency enables inspection and inspection enables adaptation; inspection without transparency is misleading, and inspection that never turns into adaptation is pointless. The link that breaks most often in practice is the first one. If an item has been sitting in the "In Progress" column for three weeks and is described as "almost done" in every Daily Scrum, the team believes it is inspecting, but it is looking at the wrong data. Every event in Scrum exists to run these three pillars; the Guide defines each event as a formal opportunity to inspect and adapt the artifacts.

Lean Thinking and the Problem Scrum Solves

The second foundation the 2020 version adds to Scrum theory is lean thinking: reducing waste and focusing on the essentials. For a software team, waste has familiar faces: features nobody uses, half-finished branches waiting for weeks, knowledge lost in hand-offs between two teams, defects piling up behind "we'll test it later". The Guide does not list them one by one; it states lean thinking as a principle and ties the short, fixed length of the Sprint, the usable Increment of every Sprint and the self-managing Developers to it.

So which problem does Scrum solve? The Guide's answer is "complex problems". Think of Bookstore's return flow: why do customers want to return things, how does the shipping company's API (Application Programming Interface) produce a return label, does the payment provider support partial refunds, which fields does accounting need to see? Nobody knows half of this on day one. You could make a six-month plan, but it would be stale after the first customer feedback. Scrum promises two things here: seeing a real, working piece at the end of every Sprint, and being able to change course within one month at most. The Guide phrases this as an iterative, incremental approach to optimize predictability and control risk.

For simple work, Scrum can be pure overhead. A rhythm of five events is expensive for a report that is regenerated every month in the same format with no surprises. Which life cycle fits which kind of work is discussed in the SDLC (Software Development Life Cycle) series post "Choosing the Right SDLC Model for Your Project, Team and Risk Profile"; for support work that arrives continuously and unpredictably, the flow approach of the Kanban series may fit better.

Five Values: Commitment, Focus, Openness, Respect, Courage

The values section, added to the Guide in 2016, says the successful use of Scrum depends on people becoming more proficient in living five values. Values sound abstract, so here is one scene per value from Bookstore:

• Commitment: The team commits to the Sprint Goal and supports each other; when Emre finishes his item, he helps Zeynep with the screen she is stuck on instead of starting a new item.
• Focus: The work of the Sprint comes first; Selin puts a "small report" request that arrives mid-Sprint into the Product Backlog instead of passing it straight to the team.
• Openness: Deniz says in the Daily Scrum that the refund amount is off by a cent on staging, rather than waiting with "we'll fix it before the Review".
• Respect: Can's pipeline proposal is not brushed off as "the DevOps guy's thing"; the team treats everyone as capable, independent professionals.
• Courage: On day three, Ayşe tells Selin that the Sprint Goal will not hold with this scope, and they renegotiate the scope together.

The values are not decoration; they decide whether the events work at all. Without openness, nobody raises problems in the Daily Scrum and transparency collapses. Without courage, everyone silently says "fine" to an unrealistic plan in Sprint Planning. The Guide says the values bring the pillars to life and build trust.

What the Guide Does Not Say

Back to the four sentences. Only the last one is in the Guide: Sprints are fixed-length events of one month or less. The other three are so common in practice that many teams think they are Scrum itself:

• Story points and velocity do not appear in the Guide. It only says that the more the Developers know about their past performance, upcoming capacity and Definition of Done, the more confident they will be in their forecast. Estimation technique belongs to the upcoming Estimation and Planning series.
• A user story is one way of writing a Product Backlog item, not part of Scrum; the Guide only says attributes such as description, order and size vary with the domain of work. Writing technique belongs to the upcoming Requirements Analysis series.
• The "what did I do yesterday, what will I do today, is anything blocking me" questions were an example in the 2017 Guide; the 2020 version removed them entirely.
• Burndown charts have not been mandatory since 2011. The 2020 Guide says practices such as burn-downs, burn-ups and cumulative flows are useful but do not replace empiricism.

This distinction is not a certification-exam detail. If a team believes "velocity is mandatory in Scrum", it blames the framework when velocity drops; in fact the problem lies in a practice the team chose and is free to change. The end note of the Guide says it in both directions: implementing only parts of Scrum is possible, but the result is not Scrum; and Scrum works well as a container for other techniques.

Preparing for the First Sprint

Before Monday, the Bookstore team gathers what the Guide actually asks for. The list is short and reads like a map of the first seven posts in this series:

Notice what is missing: a Jira setup, story point training, a preparation Sprint called "Sprint 0" that delivers nothing. None of these is required by the Guide. The team aims for a usable Increment, however small, from the very first Sprint, and the first Sprint Goal reflects that: "A registered customer can create a return request for a delivered single-item order, and the request shows up in the support panel."

In Production: What to Watch

When bringing Scrum into an organization, the most measurable signal is whether the Increment is really usable. If after three Sprints there is nothing "clickable on staging and meeting the Definition of Done", the problem is not the meeting format; it is in how work is sliced or in the engineering practices. Kerem tracks this at Bookstore with a simple question: what did a stakeholder try with their own hands in the Sprint Review?

The second signal is whether adaptation actually happens. If the order of the Product Backlog never changes after a Review, and none of the improvements from a Retrospective are applied in the next Sprint, inspection happens but produces nothing. The Guide names this plainly: inspection without adaptation is pointless.

An early warning on scale as well: the Guide describes the team as "typically 10 or fewer people". When Bookstore grows into two teams, the Guide's advice is several cohesive Scrum Teams on the same product with one Product Goal, one Product Backlog and one Product Owner. The last post of the series touches on this briefly through Nexus.

Common Pitfalls

Reducing Scrum to an event calendar is the most common pitfall. The calendar has a Daily Scrum, Planning and Review; but there is no usable Increment at the end of the Sprint, stakeholders do not come to the Review and the Retrospective produces no action. That is doing the form of Scrum and skipping its theory; it is exactly the Zombie Scrum of the tenth post in this series.

The second pitfall is treating practices that are not in the Guide as rules. Clinging to velocity, a user story template or the three questions locks the team into practices that may not fit its context. There is a reverse pitfall too: skipping a part that really is required, such as the Definition of Done, with "the Guide doesn't say how".

The third is applying Scrum to every kind of work. Production support, most of which arrives unplanned, resists being gathered around a two-week Sprint Goal. Such a team either keeps breaking its Sprint Goal or writes a fake one. The "Agile = Scrum" misconception in the Agile Mindset series post "Agile Myths: No Documentation, No Planning and 'Agile Means Scrum'" grows from the same root.

A Small Experiment

★☆☆ Write down five of your team's current practices (for example story points, three questions in the Daily Scrum, Definition of Done, Sprint 0, Retrospective). Next to each, write "in the Guide" or "a practice the team chose". Open the web version of the Guide and check how many you misclassified.

★★☆ Take the last piece of work you finished and question the three pillars one by one: how visible was the work, when was it inspected, and what changed as a result of the inspection? Find the weakest link and propose one concrete improvement.

★★★ Instead of Bookstore's return flow, pick a complex problem from your own product. Write down three things you do not know and, for each, answer "at the end of which Sprint, with which Increment, can I learn this?" If you cannot answer, the problem may not be complex, just big; then a different life cycle may fit better.

The next post looks at where the seven people on the Bookstore team fit in Scrum: why "accountability" replaced the word "role" in 2020, why the Product Owner is one person, and what separates a Scrum Master from a meeting secretary.