Scrum Principles: What Scrum Actually Defines and What It Does Not

The Scrum Guide does not contain the word principles. Scrum is founded on empiricism and lean thinking, and what it formally defines are three pillars, transparency, inspection and adaptation, and five values, commitment, focus, openness, respect and courage. The lists of six or seven Scrum principles you will find elsewhere come from other organisations, which is why sources disagree with each other.

Key Highlights

• Scrum is founded on empiricism and lean thinking. Empiricism means knowledge comes from experience and decisions are made on what is observed.
• The three pillars are transparency, inspection and adaptation. These are what the Scrum Guide actually defines.
• The five values are commitment, focus, openness, respect and courage.
• The relationship matters: when the values are lived, the pillars work, and trust follows.
• The commonly cited six Scrum principles come from SCRUMstudy's body of knowledge, not from the Scrum Guide.
• Sources listing seven principles are describing something else again, which is why the counts never match.

Why Sources Disagree

Search for Scrum principles and you will find lists of six, lists of seven, and pages that mix pillars, values and principles together as though they were one set. The disagreement is not sloppiness so much as several different organisations publishing different things under a similar name.

The Scrum Guide. Written by the framework's creators and the closest thing to an authoritative definition. It does not use the word principles at all. It describes Scrum as founded on empiricism and lean thinking, defines three pillars, and defines five values.

SCRUMstudy. A separate organisation with its own body of knowledge, which does define six principles: empirical process control, self organisation, collaboration, value based prioritisation, time boxing and iterative development. These are coherent and useful, and they are SCRUMstudy's framing rather than the Scrum Guide's.

The Agile Manifesto. Sets out twelve principles behind the manifesto. These are about agile generally rather than Scrum specifically, and a good deal of what people call Scrum principles is actually drawn from here.

Various training providers and blogs. Which combine the above in different proportions, producing the sixes and sevens.

None of these is wrong within its own frame. The confusion comes from treating them as competing accounts of one thing rather than as different documents with different purposes. If you are studying for a Scrum Alliance or Scrum.org certification, the Scrum Guide is the source that matters.

If you want to check where your understanding sits, our free CSM practice test takes a few minutes.

What Scrum Is Founded On

Two ideas sit underneath everything else, and they are the closest thing Scrum has to principles in the ordinary sense.

Empiricism. Knowledge comes from experience, and decisions are made based on what is observed. This is why Scrum works in short cycles: you cannot plan your way to certainty in complex work, so you build something, look at what happened, and adjust. Every event in Scrum exists to create a point where observation informs a decision.

Lean thinking. Reduce waste and focus on the essentials. This is why the framework is deliberately minimal, and why adding process to Scrum usually makes it worse rather than better.

Those two explain most of the design decisions people find puzzling. Why are Sprints short? So observation happens sooner. Why is there so little documentation? Because it is not essential to the outcome. Why is the framework so sparse? Because anything added has to earn its place.

The Three Pillars

Empiricism is implemented through three pillars, and the Scrum Guide names them explicitly.

Transparency. The work and the process must be visible to those doing the work and those receiving it. Decisions are only as good as what they are based on, so hidden problems produce bad decisions. This is why the artefacts exist and why the Definition of Done matters.

Inspection. Progress and artefacts must be examined frequently to detect problems. Inspection without transparency inspects a fiction, which is why the order matters.

Adaptation. If inspection reveals something is off course, adjust. An inspection that changes nothing was pointless, which is the most common failure across all three.

The pillars are sequential in practice. Transparency makes inspection meaningful, inspection makes adaptation informed, and adaptation is where the value is realised. Teams that run every event on schedule while changing nothing have transparency and inspection and no adaptation, so they get none of the benefit. Our guide to the three pillars of Scrum covers each in more depth.

The Five Values

The Scrum Guide defines five values: commitment, focus, openness, respect and courage.

Commitment. To the Product Goal and to each other. Not committing to a scope forecast, which is a common misreading, but committing to doing your best work toward a shared aim.

Focus. On the Sprint Goal and the work of the Sprint. This is what makes a Sprint a container rather than a period of time in which anything might happen.

Openness. About the work and the challenges. This is transparency expressed as behaviour rather than as an artefact.

Respect. For each other as capable, independent people. The practical version is not assuming someone is wrong before understanding why they think what they think.

Courage. To do the right thing and work on hard problems. Usually the hardest of the five, because it means raising things people would rather not hear.

The relationship the Scrum Guide draws between values and pillars is worth understanding rather than memorising. When the values are embodied by the team and the people around them, the pillars come to life and trust is built. In other words, the values are what make the mechanics work. A team with all the events and none of the values produces the appearance of Scrum and very little of the substance, which our guide to the Scrum values explores in more detail.

The Six Principles You Will See Elsewhere

Worth covering properly, since a great many readers arrive having seen this list and wanting to know where it fits.

SCRUMstudy, an organisation with its own certification track and body of knowledge, defines six Scrum principles.

Every one of these is a real and useful idea, and most of them appear in the Scrum Guide in different form. Empirical process control is the three pillars. Self organisation appears as self management. Time boxing appears in the events. Value based prioritisation appears in the Product Owner's accountability for backlog ordering.

The distinction to hold is that this is a framing rather than a competing definition. If someone asks about the six principles of Scrum, they have read a SCRUMstudy derived source. If you are answering a CSM or PSM exam question, the Scrum Guide's pillars and values are what is being tested.

The Twelve Agile Principles

The other thing people mean, and it belongs to a different document again.

The Agile Manifesto sets out four values and twelve principles behind them. Those principles cover satisfying the customer through early and continuous delivery, welcoming changing requirements, delivering frequently, business people and developers working together, building projects around motivated individuals, face to face conversation, working software as the measure of progress, sustainable pace, technical excellence, simplicity, self organising teams, and regular reflection and adjustment.

Scrum is one way of implementing those ideas rather than a restatement of them. A team can follow the manifesto without using Scrum, and it is possible to run all the Scrum events while violating most of the twelve principles, which is the more common failure.

Our guide to the Agile Manifesto principles and values covers all twelve in detail, and the relationship between agile broadly and Scrum specifically is worth understanding before an interview, where the two get conflated regularly.

Where the Pillars Break Down

Each pillar has a characteristic failure, and naming them makes the abstractions checkable.

Transparency fails quietly. Not through deliberate concealment but through omission: an item marked done that is not quite, an estimate given to end a conversation, a risk everyone knows about and nobody has written down. The tell is a Sprint Review where something surprises people who should have known.

Inspection fails by becoming ceremonial. The event happens, the board is reviewed, the questions are asked, and nobody examines anything uncomfortable. Attendance is not inspection. The tell is a Retrospective that produces the same three observations every Sprint.

Adaptation fails most often and most invisibly. A team can be genuinely transparent and genuinely inspecting, and then change nothing, either because the change sits above them or because nobody owns it. The tell is a list of improvement actions where most are still open from two months ago.

The order matters when diagnosing. If adaptation is not happening, check whether inspection is real before assuming the team lacks willingness. If inspection is producing nothing, check whether transparency exists before improving the meeting. Teams routinely try to fix the third by working on the third, when the cause is the first.

This is also the practical value of understanding the pillars rather than reciting them. Transparency, inspection and adaptation are not three virtues to aspire to; they are a chain, and knowing which link is broken tells you what to actually do. Recognising that is a substantial part of the Scrum Master's diagnostic work, and it is covered directly in CSM Certification Training.

Answering This in an Exam or Interview

A practical note, since this topic appears in both.

If asked about Scrum principles in a CSM or PSM context, the safe and correct answer describes empiricism and lean thinking as the foundation, then names the three pillars and the five values. Noting that the Scrum Guide does not use the term principles demonstrates you have read the source rather than a summary of it.

If asked in an interview, the same answer works and the follow up matters more. Being able to say what transparency looks like when it is absent, or what courage means on a Tuesday afternoon, distinguishes someone who has practised from someone who has memorised a list.

If someone cites the six principles, there is no need to correct them. They are describing a legitimate framework from a different organisation, and knowing that both exist is more useful than insisting on one.

What is worth avoiding is reciting a list of six or seven principles in a Scrum Alliance or Scrum.org exam, since neither body uses them and the answer will not match what is being assessed.

How the Values Show Up in Practice

Abstract values are easy to agree with and hard to act on, so here is what each looks like when it is genuinely present.

Commitment. A team that says an item will not fit rather than accepting it to end a conversation.

Focus. A Sprint where the team declines a mid Sprint request that threatens the Sprint Goal, rather than absorbing it silently.

Openness. A Retrospective where someone raises the real problem instead of the comfortable one, and the room stays with it rather than moving on quickly.

Respect. A disagreement in refinement where both people are trying to understand the other position rather than win.

Courage. A Scrum Master telling a senior stakeholder that the funding model is causing the delivery problem they are complaining about, knowing it will not be a comfortable conversation.

Each of those is observable. That is the useful test, because values discussed as adjectives produce nothing and values described as behaviours can be noticed, coached and improved. A team that cannot point to a recent example of any of the five has a gap worth examining, and that examination is a natural fit for a Retrospective, as our guide to agile maturity levels discusses in the context of a team's overall development.

Why the Framework Is Deliberately Small

Lean thinking gets less attention than empiricism and it explains something people frequently complain about.

Scrum is minimal by design. Three accountabilities, four events inside a containing fifth, three artefacts. Nothing about estimation technique, nothing about how to write a requirement, nothing about tooling, engineering practice or team size beyond a rough guide.

People read that as incompleteness and it is a choice. Reducing waste and focusing on the essentials means the framework defines only what is necessary for empiricism to function, and leaves everything else to the team. What to add is context dependent, so prescribing it would make the framework wrong more often than right.

Two consequences follow.

Scrum will feel insufficient at first. Teams new to it reasonably ask where the guidance is on estimation, refinement technique or engineering practice. The answer is that those are the team's to choose, which is uncomfortable before it becomes liberating.

Additions should be justified. Every practice a team adds carries cost. That does not make additions wrong, and it does mean the question is what this produces rather than whether other teams do it. A team that has accumulated practices nobody can justify has drifted from lean thinking regardless of how well it runs the events.

The most common version of this is a team with more process than it needs, defended on the grounds that removing anything feels risky. Noticing which practices have stopped earning their place, and being willing to drop one, is a genuine improvement rather than a lapse in rigour, and it follows directly from the second thing Scrum is founded on.

Closing Thoughts

The question has a slightly unsatisfying answer: Scrum does not define principles, and the lists circulating under that name come from elsewhere. Knowing that is more useful than memorising any of them, because it explains why every source you check gives you something different.

What Scrum does define is worth learning properly. Empiricism and lean thinking explain why the framework is shaped the way it is. The three pillars explain how empiricism is put to work. The five values explain why teams with identical practices get such different results.

That last point is the one worth carrying. Transparency, inspection and adaptation are mechanical and a team can go through all three while changing nothing. The values are what turn the mechanics into something that works, and they are the part no process can enforce.

If you are building that understanding for a certification or for a role, CSM Certification Training covers the framework as the Scrum Guide defines it, along with the practical facilitation that makes the values more than a poster. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to find your gaps first.