Scrum (Scrum.org PSM / PSPO / PSD) learning path: everything to study, topic by topic

The theory behind Scrum: empirical process control built on transparency, inspection and adaptation, the difference from defined (predictive) processes, lean thinking, and how each Scrum event provides a formal opportunity to inspect and adapt

Commitment, Focus, Openness, Respect and Courage: what each value means in practice, how the values support the pillars, and how a Scrum Master recognizes and addresses behavior that violates them

Scrum as a lightweight framework: the single Scrum Team, five events, three artifacts with their commitments, rules that bind them together, what the 2020 Guide changed (no Development Team, Product Goal, Sprint Goal as commitment, self-managing, no three questions) and what Scrum deliberately leaves unspecified

Recognizing 'Scrum-but', mini-waterfall sprints, status-meeting Daily Scrums, the Scrum Master as project manager, velocity as a target, hardening sprints and other deviations, and responding to them with the Scrum Guide as reference while keeping the framework whole

The Scrum Master as a true leader accountable for the Scrum Team's effectiveness: serving the team (coaching, focus on Increments that meet the Definition of Done, removing impediments, keeping events positive and timeboxed), the Product Owner and the organization, and what a Scrum Master is not

One person accountable for maximizing the value of the product resulting from the Scrum Team's work: developing and communicating the Product Goal, creating and ordering Product Backlog items, ensuring transparency, what may be delegated, and the organization's duty to respect the Product Owner's decisions

Developers are the people committed to creating any aspect of a usable Increment each Sprint: creating the Sprint plan, instilling quality through the Definition of Done, adapting the plan daily toward the Sprint Goal and holding each other accountable as professionals; who counts as a Developer

The Scrum Team as one unit of focus with no sub-teams or hierarchies, small enough (typically ten or fewer) and cross-functional, self-managing who, what and how; growing self-management, team size trade-offs, collaboration with stakeholders and what a manager can still do

The Sprint as the heartbeat and container event: fixed length of one month or less, consistency, no changes that endanger the Sprint Goal, scope clarification and renegotiation, who can cancel and when, and why Sprints are not extended

The three topics of Sprint Planning: why the Sprint is valuable (Sprint Goal), what can be done (Developers select Product Backlog items) and how the work will get done (plan); inputs, timebox of eight hours for a one-month Sprint, and the roles of each accountability

A 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog: structure chosen by the Developers, same time and place, who attends and who owns it, and why it is not a status report to management

A working session to inspect the outcome of the Sprint and determine future adaptations: Scrum Team and key stakeholders, progress toward the Product Goal, reviewing the Product Backlog and the market, four hours for a one-month Sprint, and how it differs from a demo or sign-off

The event that plans ways to increase quality and effectiveness: inspecting individuals, interactions, processes, tools and the Definition of Done, identifying the most helpful changes, addressing them as soon as possible, a three-hour timebox, and keeping improvements flowing into the next Sprint

The Product Backlog as the single, emergent, ordered list of what is needed to improve the product, the Product Goal as its long-term objective and commitment, refinement as ongoing work, items small enough for a Sprint, and transparency of ordering

The Sprint Backlog as the Sprint Goal (why), the selected Product Backlog items (what) and the plan for delivering them (how), owned by the Developers and updated throughout the Sprint; the Sprint Goal as the commitment that gives flexibility

The Increment as a concrete, usable step toward the Product Goal, additive and verified, the Definition of Done as the commitment that creates transparency, organizational versus team standards, handling work that is not Done, and evolving the Definition of Done

Forecasting delivery with empirical data rather than promises: burn-up and burn-down charts, throughput and cumulative flow, Monte Carlo ranges, release planning with uncertainty, why velocity is not a commitment, and keeping artifacts transparent for decisions

The stances a Scrum Master moves between: servant leader, facilitator, coach, teacher, mentor, manager, impediment remover and change agent; choosing the right stance for a situation and avoiding staying in one stance (such as always fixing)

Facilitating events and decisions without taking over: preparing, divergence and convergence, decision techniques, handling dominant voices and silence, conflict between Developers or with the Product Owner, dysfunctions and how a Scrum Master intervenes with minimum force

Evolving the organization around Scrum Teams: organizational impediments, culture and structure, middle management roles, leadership styles from directive to empowering, working with stakeholders, and how a Scrum Master leads, trains and coaches Scrum adoption across the organization

Using evidence to improve value: the four Key Value Areas (Current Value, Unrealized Value, Time-to-Market, Ability to Innovate), key value measures, goals and experiments, avoiding vanity and output metrics, and using measures to inspect and adapt rather than to judge people

Creating value with Scrum: product vision and strategy alignment, value definition and measurement, customers and users versus stakeholders, collaborating at the Sprint Review and between events, saying no, and managing expectations around fixed scope and date

Refinement as an ongoing activity that adds detail, estimates and order; Developers own sizing; splitting items vertically, acceptance criteria, relative estimation, Planning Poker, reference stories, throughput and #NoEstimates, and keeping estimates useful rather than precise

TDD red-green-refactor, unit and integration tests, test pyramid, behavior-driven development and acceptance tests, test automation versus manual exploratory testing, regression suites, and test doubles; testing inside the Sprint rather than after it

Continuous integration, deployment pipelines, trunk-based development, feature toggles, infrastructure as code, environments, automated quality gates, monitoring and feedback loops, and DevOps culture as a way to keep Done releasable

Technical debt as the cost of earlier shortcuts, visible versus hidden debt, refactoring, clean code, code metrics, emergent design and evolutionary architecture, and how the Definition of Done and the Product Backlog make quality and debt transparent

Pair programming, mob programming, code review, collective code ownership, shared coding standards, cross-skilling (T-shaped people) and swarming on backlog items, balancing collaboration against individual flow, and how these practices support a cross-functional team

Identifying and reducing technical risk early: spikes and prototypes, walking skeletons, non-functional requirements (security, performance, reliability), dependencies and integration, proof of concept, and handling uncertainty through small experiments inside the Sprint