Scrum is founded on empiricism - the idea that knowledge comes from experience and decisions are made based on what is observed, not detailed upfront planning.
This matters because software work is complex and unpredictable, so you inspect the real product and adapt rather than trust a fixed plan.
A common mistake is thinking these are three separate steps done once - really they run continuously and depend on each other. Without transparency, inspection is misleading and adaptation becomes pointless.
Commitment, Focus, Openness, Respect and Courage. People must live these values for empiricism to work - they build the trust needed for real transparency. This is often tested indirectly (a scenario showing a team hiding problems is a values failure, not just a process failure).
Scrum is designed for complex work (unpredictable, unknown-unknowns) rather than complicated work (knowable but hard). The Stacey Matrix idea sits behind this even though it is not officially part of the Guide - expect exam questions that test whether you understand Scrum suits complex, adaptive problems, not simple repeatable ones.
Transparency lets you Inspect honestly, Inspection lets you Adapt correctly - break the chain anywhere and empiricism fails.
A Scrum Team is small, self-managing, and cross-functional. It has no sub-teams or hierarchies. Total size is typically 10 people or fewer (the Scrum Guide's guidance), though earlier framings used 3-9 developers plus PO and SM. Small enough to stay nimble, big enough to complete meaningful work in a Sprint.
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. There is only ONE Product Owner and ONE Scrum Master per Scrum Team - never more, and these are not committees. The whole Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Accountable for maximising the value of the product resulting from the work of the Scrum Team. Owns the Product Backlog: creating and communicating items, ordering them, and making sure they are transparent and understood. The Product Owner may delegate backlog work but remains accountable. For the Product Owner to succeed, the whole organisation must respect their decisions - nobody can tell the Developers to work from a different set of priorities, and nobody can force the PO's hand.
The people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. They are self-managing (they decide who does what, when, and how - nobody, including the Scrum Master or PO, assigns their work). Accountable for creating the Sprint Plan (the Sprint Backlog), instilling quality by adhering to a Definition of Done, adapting their plan daily toward the Sprint Goal, and holding each other accountable as professionals.
Accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. A true leader who serves the Scrum Team and the wider organisation - NOT a project manager, NOT an admin, and NOT the Developers' boss. Serves in three directions:
Scrum has five events (some call them 'ceremonies'), all designed to create regular inspection and adaptation opportunities and to limit the need for meetings not defined in Scrum. They are: the Sprint itself, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. All events happen inside the Sprint - the Sprint is a container for all the others.
Scrum has three artifacts: the Product Backlog, the Sprint Backlog, and the Increment. Each artifact carries a 'commitment' that adds transparency and focus.
These commitments stop the artifacts being just lists of stuff - they give each one a purpose to measure progress against.
An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. It is never complete - it evolves as long as the product exists.
Made up of the Sprint Goal (why), the selected Product Backlog items (what), and an actionable plan for delivering the Increment (how).
A concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and must be usable, regardless of whether the Product Owner decides to release it.
A formal description of the state of the Increment when it meets the quality measures for the product. Work that does not meet it cannot be released or even presented as done.
The Definition of Done (DoD) is a formal, shared description of the state a product Increment must be in to be releasable.
It is used to assess when work on a Product Backlog item is complete.
If multiple Scrum Teams work on the same product, they must mutually define and comply with the same Definition of Done.
The DoD creates transparency by giving everyone a common, objective understanding of what 'complete' means, so an Increment is genuinely inspectable.
If a Definition of Done is not supplied by the organisation, the Scrum Team must create one appropriate for the product.
Developers are required to conform to the Definition of Done - they cannot create an Increment that does not meet it.
Organisational standards, if they exist, are a mandatory baseline; the team can add to them but cannot weaken them.
The DoD can evolve over the life of a product as the team's capability and standards mature.
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented as done at the Sprint Review as finished work.
It returns to the Product Backlog for future consideration - it does not count towards the Increment.
A common misconception: 'partially done' work is still not Done - there is no partial credit in Scrum's inspection model.
Transparency means significant aspects of the process must be visible to those responsible for the outcome.
Without transparency, the other two pillars (inspection and adaptation) are meaningless - you cannot inspect what you cannot see, and you cannot adapt based on flawed data.
Artifacts low in transparency (hidden problems, vague DoD, undisclosed risk) lead to decisions that reduce value and increase risk.
The Scrum Master helps everyone - including the organisation - understand and enact Scrum, which includes coaching genuine transparency, not just visible artifacts.
The Scrum Guide itself describes Scrum as a framework for one team, but explicitly notes Scrum can be used by multiple teams producing one product.
When several Scrum Teams work on one product, they must share a single Product Backlog and a single, unified Definition of Done - this is essential for one coherent, releasable Increment.
The Scrum Guide does not prescribe a specific scaling framework (Nexus, LeSS, SAFe etc.) - PSM I tests the Guide itself, not any named scaling model.
Nexus is Scrum.org's own scaling framework, built directly on top of Scrum, adding a Nexus Integration Team and cross-team refinement to manage dependencies and integration.
The Scrum Master is a servant leader for the Scrum Team and the wider organisation. This means leading by serving, coaching and removing obstacles rather than directing, assigning tasks or managing people. PSM I questions often test whether you can spot bad Scrum Master behaviour dressed up as 'helping'.
Think: teach, coach, facilitate, remove impediments, protect the process - never command, assign or decide on the team's behalf.