The Certified ScrumMaster (CSM) is Scrum Alliance’s entry-level Scrum Master credential, and it is different from most certifications in one decisive way: you cannot simply book the exam. You must first complete a 16-hour official CSM course taught by a Certified Scrum Trainer (CST), and only then are you eligible to sit a short, open-book exam. This shapes everything about how you prepare. The real learning happens in the live course, and your job before and after it is to arrive ready and to lock the material in while it is fresh. The exam confirms understanding rather than acting as a high barrier in its own right. This guide is a full self-study companion to that journey. It teaches the Scrum framework in depth, area by area, so the course deepens a foundation rather than starting from zero, and so you can answer fluently under time. It is original teaching material only, contains no real or simulated exam questions, and you should confirm current rules with Scrum Alliance and the free Scrum Guide before you book.
Chapter 1: The CSM at a glance and how to use this guide
What the CSM is, and what makes it distinctive
The CSM certifies that you understand the Scrum framework and the Scrum Master role well enough to support a Scrum team. Its distinctive feature, the mandatory CST course, means you are paying for training as much as for a badge, and that is the right way to think about its value: the structured, instructor-led start is the benefit, and the certificate records it. No prior Scrum experience is required to enrol, which makes the CSM a common first step into agile for people coming from development, product, project management, or stakeholder roles. If you specifically want a self-study, exam-first route with no required course, that is the Professional Scrum Master (PSM) from Scrum.org instead, and the CSM vs PSM comparison lays out the trade-off.
How the exam works
After the course you take an exam of 50 multiple-choice questions in 60 minutes, open book, online, and non-proctored. The pass mark is 37 out of 50, which is 74%, and the course fee usually includes two attempts. “Open book” is genuinely helpful, but it is a trap to read it as “no study needed”: with 50 questions in 60 minutes you have little more than a minute each, so you must understand Scrum well enough to answer from knowledge and use your notes only to confirm, not to learn during the exam. The credential is valid for two years and is renewed with Scrum Education Units (SEUs) plus a renewal fee.
How to use this guide around the course
The chapters follow the structure of the Scrum framework itself: empiricism and values first, then the three accountabilities, the five events, the three artifacts, and finally the Scrum Master role that ties them together. Read them once before your course so the vocabulary is familiar and the trainer is deepening rather than introducing each idea, and read them again straight afterwards as your structured review. Treat the bold terms as a checklist you should be able to explain in a sentence. None of the examples here are exam questions; they are teaching illustrations.
Chapter 2: Scrum theory, empiricism, and values
Everything in Scrum rests on a single idea, and the exam returns to it constantly: Scrum is built on empiricism, the belief that knowledge comes from experience and that decisions should be based on what is observed rather than on detailed up-front prediction. Understanding this is what separates someone who has memorised the events from someone who understands why they exist.
The three pillars of empiricism
Empirical process control stands on three pillars, and you should be able to name each and say what it means in practice. Transparency means the work and the process are visible to the people doing and receiving the work, because you cannot make good decisions about something you cannot see honestly. Inspection means frequently checking the artifacts and progress toward agreed goals so that problems and deviations are spotted early. Adaptation means adjusting the work or the process as soon as inspection shows it is needed. The reason this matters for the whole framework is that each Scrum event is, at heart, a formal opportunity for inspection and adaptation supported by transparency. As a teaching illustration, the Daily Scrum exists so the Developers can inspect their progress toward the Sprint Goal and adapt their plan for the day; strip away the empiricism and the event becomes a pointless status meeting, which is exactly the misunderstanding the exam probes.
The five Scrum values
Alongside the pillars sit the five Scrum values, which describe how a healthy Scrum team behaves: commitment to the goals and to each other, focus on the work of the Sprint, openness about the work and the challenges, respect for each other as capable and independent people, and courage to do the right thing and tackle hard problems. The exam treats these not as decoration but as the cultural conditions that make empiricism work, since transparency depends on openness and courage, and inspection and adaptation depend on commitment, focus, and mutual respect. When a scenario describes a team hiding bad news or refusing to confront a problem, the values are what name the gap.
Lean and agile roots
Finally, place Scrum in its wider context. Scrum is a lightweight framework that sits within agile ways of working and draws on lean thinking, particularly the lean instinct to reduce waste and maximise value. You do not need a deep treatise on either, but you should recognise that Scrum is one specific framework for delivering value in short cycles, not a synonym for “agile” as a whole, and that its rules are deliberately minimal so that teams can inspect and adapt their way to what works in their context.
Chapter 3: The three Scrum accountabilities
A Scrum Team is small, cross-functional, and self-managing, and it is made up of three accountabilities (often called roles): the Scrum Master, the Product Owner, and the Developers. The exam tests that you know precisely what each is accountable for and, just as importantly, what each is not, because a great many questions hinge on someone in a scenario stepping into the wrong lane.
The Product Owner
The Product Owner is accountable for maximising the value of the product that results from the team’s work. The lever they hold is the Product Backlog: they own it, order it, and keep it transparent so the team always works on the most valuable thing next. The Product Owner is one person, not a committee, and although they may take input from many stakeholders, the decision about ordering rests with them so that the team has a single, clear source of priority. The teaching point the exam rewards is that value and prioritisation are the Product Owner’s domain, so a scenario where someone else quietly reorders the backlog, or where priorities come from several conflicting voices, points to a Product Owner accountability being undermined.
The Developers
The Developers are the team members who do the work of building a usable Increment each Sprint. The word covers everyone who contributes to creating the product, not only programmers, so testers, designers, analysts, and writers are all Developers in Scrum terms if they are doing the work. They are accountable for the quality of their work through the Definition of Done, for creating a plan for the Sprint (the Sprint Backlog), and for adapting that plan each day. Crucially, the Developers are self-managing: they decide internally who does what and how the work gets done, rather than being assigned tasks by a manager. That self-management is a frequent exam theme.
The Scrum Master
The Scrum Master is accountable for the team’s effectiveness and for the team and organisation understanding and applying Scrum. The defining word is service: the Scrum Master is a servant leader who helps others succeed rather than directing them. Chapter 6 treats this role in depth because it is the lens of the whole exam, but hold the core distinction now: the Scrum Master does not assign work, does not own priorities, and is not a project manager in disguise. When a scenario has the “Scrum Master” telling Developers what to build or deciding the backlog order, that is almost always the wrong behaviour the question is testing you to spot.
Chapter 4: The five Scrum events
Scrum contains five events, and the most important framing to carry is that they are not arbitrary meetings: each is a designed opportunity for inspection and adaptation, and each is time-boxed so it does not sprawl. Being able to say what each event is for, who is involved, and who facilitates it resolves a large share of exam questions.
The Sprint
The Sprint is the heartbeat of Scrum and the container for all the other events. It is a fixed-length cycle of one month or less, and a new Sprint starts immediately after the previous one ends, so the team works in a steady, unbroken rhythm. Within a Sprint, no changes are made that would endanger the Sprint Goal, quality does not drop, and scope may be clarified and renegotiated with the Product Owner as more is learned. The reason the Sprint length is capped at a month is empirical: a shorter horizon limits how far the team can drift before it inspects and adapts, which controls risk.
Sprint Planning, the Daily Scrum, and the work of the Sprint
A Sprint begins with Sprint Planning, where the whole Scrum Team plans the Sprint: why the Sprint is valuable (the Sprint Goal), what can be done, and how the chosen work will be tackled. The output is the Sprint Backlog. Each working day, the Developers hold the Daily Scrum, a 15-minute event for them to inspect progress toward the Sprint Goal and adapt their plan for the next day. The Daily Scrum belongs to the Developers, a detail the exam likes to test: it is not a status report to the Scrum Master or the Product Owner, and the Scrum Master’s job is to ensure it happens and stays within its time-box, not to run it.
Sprint Review and Sprint Retrospective
Near the end of the Sprint, the Sprint Review brings the Scrum Team and stakeholders together to inspect the Increment and adapt the Product Backlog in light of what was achieved and what has changed. It is a working session about the product, not a formal sign-off ceremony. The Sprint then closes with the Sprint Retrospective, where the Scrum Team inspects how it worked, considering people, relationships, process, and tools, and plans improvements for the next Sprint. The clean way to hold the pair is that the Review inspects the product while the Retrospective inspects the process, and both feed adaptation: one adjusts what to build next, the other adjusts how to build it.
Chapter 5: The three Scrum artifacts and their commitments
Scrum has three artifacts, and each one carries a commitment that gives it focus and makes progress measurable. The pairing of artifact to commitment is one of the most reliably tested pieces of the framework, so learn the three couplings cold.
The Product Backlog and the Product Goal
The Product Backlog is an ordered, ever-evolving list of everything that might be needed in the product. It is the single source of work for the Scrum Team, and the Product Owner is accountable for it. Its commitment is the Product Goal, the longer-term objective the product is working toward, which gives the backlog a target so that ordering is not arbitrary but serves a destination. Items near the top are smaller and clearer than items lower down, because the team refines them as they approach, a continuous activity called Product Backlog refinement.
The Sprint Backlog and the Sprint Goal
The Sprint Backlog is the Developers’ plan for the Sprint. It is made up of three things: the Sprint Goal (the why), the set of Product Backlog items selected for the Sprint (the what), and an actionable plan for delivering the Increment (the how). Its commitment is the Sprint Goal, the single objective for the Sprint, which creates coherence and gives the Developers flexibility about exactly which items to do as long as the goal is met. The Sprint Backlog belongs to the Developers and is updated by them throughout the Sprint as they learn.
The Increment and the Definition of Done
The Increment is a concrete, usable step toward the Product Goal, and each Sprint may produce one or more of them. An Increment only counts if it meets the Definition of Done, its commitment, which is the shared, agreed set of quality criteria that an Increment must satisfy to be considered complete. The Definition of Done is what makes “done” mean the same thing to everyone and prevents the quiet accumulation of half-finished work. As a teaching illustration, if a feature is coded but not tested and the team’s Definition of Done requires testing, then that feature is simply not done, regardless of how it looks in a demo, and it cannot be part of a legitimate Increment. The exam consistently rewards this strict, transparent reading of completeness.
Chapter 6: The Scrum Master as servant leader
If Chapters 2 through 5 are the structure of Scrum, this chapter is its lens, because the CSM is ultimately about how a Scrum Master thinks and behaves. The unifying idea is servant leadership: the Scrum Master leads by serving, creating the conditions for the team to succeed rather than commanding it.
Serving the team, the Product Owner, and the organisation
The Scrum Master serves on three levels, and recognising all three matters for the exam. To the Developers, the Scrum Master coaches self-management and cross-functionality, helps the team focus on creating valuable Increments, and removes impediments that block progress. To the Product Owner, the Scrum Master helps with effective Product Backlog management, clear goal definition, and techniques for ordering work by value. To the organisation, the Scrum Master leads and coaches the adoption of Scrum, helps stakeholders understand empirical product work, and removes barriers between stakeholders and the team. A Scrum Master who only “runs the team’s meetings” is doing a fraction of the role.
Facilitation, coaching, and removing impediments
Three behaviours define the day-to-day work. Facilitation means enabling good conversations and effective events without dominating them, so the team reaches its own decisions. Coaching means helping people grow in self-management and Scrum understanding, asking questions more than giving answers. Removing impediments means clearing the organisational and practical blockers the team cannot clear itself. The instinct the exam rewards in nearly every Scrum Master scenario is the same: enable and unblock the team, help them solve the problem themselves, and resist the urge to take over, decide for them, or escalate before the team has had the chance to act.
The trap to resist throughout
The single most common wrong answer across the CSM is the Scrum Master behaving like a traditional command-and-control project manager: assigning tasks, owning the backlog, deciding scope, or reporting on the team rather than serving it. Whenever two options look plausible, prefer the one that empowers the team, increases transparency, and addresses the root cause through facilitation and coaching. Building that reflex is what carries you through the judgement-flavoured questions, and it is also what makes you effective in the role afterward.
Chapter 7: Study plan, final preparation, and exam day
A plan built around the course
Because the CST course does most of the teaching, your plan is shaped around it rather than around weeks of solitary study. Before the course, read the Scrum Guide once and skim the chapters above so the three accountabilities, five events, and three artifacts are familiar; aim for recognition, not mastery, since the course will deepen them. During the 16 hours, attend actively and take notes organised into the same three buckets (accountabilities, events, artifacts) plus the values, because those notes become your open-book reference. Straight after the course, while everything is fresh, re-read the Scrum Guide and your notes and confirm you can name each piece and explain it in a sentence. To turn this into dated steps around your own course date, the free study-plan generator can help.
Reaching fluency for an open-book, timed exam
The goal of revision is fluency, not memorisation for its own sake, because 50 questions in 60 minutes leaves no time to look up more than the occasional detail. Drill the couplings that the exam loves: which event is for whom and who facilitates it, and which artifact carries which commitment (Product Backlog to Product Goal, Sprint Backlog to Sprint Goal, Increment to Definition of Done). Rehearse explaining the Scrum Master as a servant leader, since that framing answers a surprising number of questions. Use your notes to confirm answers under time pressure, not to learn the framework on the fly. Avoid “exam dump” sites that claim to sell real questions: they breach Scrum Alliance policy, and for an open-book test built on understanding they are pointless anyway.
Exam day
Sit the exam soon after the course, while the material is fresh, rather than letting it fade over weeks. It is taken online at a time you choose, with no proctor and no booking pressure: 50 multiple-choice questions in 60 minutes, open book, with a pass mark of 37 out of 50, and the course usually includes two attempts. Read each question for what it is really asking, lean on your understanding first and your notes second, and apply the Scrum Master reflex throughout: favour transparency, inspection and adaptation, empower the team, and resist the command-and-control answer. Prepared this way, the exam is a confirmation of what the course taught rather than an obstacle, which is exactly how the CSM is designed to work.