CSM Practice Test PDF (Free Printable 2026)

CSM Practice Test PDF – Free Download (2026)

Earning your csm certification from the Scrum Alliance requires passing a 50-question online assessment after completing a two-day certified Scrum course. The assessment tests your understanding of the Scrum framework in depth — the roles, events, artifacts, and the empirical principles that underlie everything. This free printable PDF gives you additional practice questions you can study away from a screen, annotate, and share with your study group before sitting the assessment.

CSM Assessment Format and Requirements

The Scrum Alliance CSM certification process differs from most technology certifications in one important way: the two-day certified Scrum course is not optional. You cannot challenge the assessment without first attending a course delivered by a Scrum Alliance Certified Scrum Trainer (CST). The course requirement exists because the Scrum Alliance believes that truly understanding Scrum requires experiencing it in a learning environment with qualified instruction — not just reading the Scrum Guide and memorizing definitions.

After completing the course, your CST will send your assessment access to the email address you registered with. You have 90 days to complete the assessment and two attempts included with the course fee. The online assessment consists of 50 questions drawn from the Scrum Guide and the course curriculum. You need to answer at least 37 questions correctly (74%) to pass. The assessment is not proctored — you take it at your own pace in your own environment — but you are expected to complete it based on your own knowledge. The time limit is 60 minutes. Most candidates who attended the full course and reviewed the Scrum Guide complete it well under the time limit.

CSM certification must be renewed every two years through the Scrum Education Units (SEU) program — you need 20 SEUs within your two-year certification period plus a renewal fee. SEUs can be earned through attending Scrum events, taking additional Scrum courses, volunteering in the Scrum community, and reading or writing Scrum-related content.

The Three Scrum Roles

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner owns the Product Backlog: ordering its items, ensuring all items are clear and understood by the Development Team, and making sure the team works on the highest-value items first. The Product Owner defines acceptance criteria — the specific, verifiable conditions that a Product Backlog item must meet before it can be considered done. The Product Owner represents stakeholder interests to the Scrum Team and is the single person accountable for backlog decisions, though the Product Owner may work collaboratively with others in making those decisions. One of the most commonly misunderstood rules on the CSM assessment is that the Product Owner's decisions must be respected — the Development Team must not be directed by anyone else to work on different priorities.

The Scrum Master is a servant-leader for the Scrum Team and for the organization. The Scrum Master serves the Development Team by coaching team members in self-organization and cross-functionality, removing impediments to progress, protecting the team from external interruptions during the Sprint, and facilitating Scrum events when needed. The Scrum Master serves the Product Owner by facilitating Product Backlog refinement, helping the Product Owner understand product planning in an empirical environment, and coaching on effective backlog management techniques. The Scrum Master serves the organization by leading and coaching the organization in its Scrum adoption, planning Scrum implementations, and helping employees and stakeholders understand and apply empirical product development. A key point tested on the CSM assessment is that the Scrum Master does not assign work to team members — the Development Team self-organizes to decide how to accomplish its Sprint goals.

The Development Team is the group of professionals who do the work of delivering a potentially releasable increment of the product at the end of each Sprint. Development Teams are self-organizing — no one outside the team (not even the Scrum Master or Product Owner) tells the team how to turn the Product Backlog into a working increment. They are cross-functional, meaning they collectively possess all the skills needed to complete the work without depending on people outside the team. The optimal Development Team size is three to nine people — fewer than three limits interaction and the range of skills available; more than nine requires too much coordination overhead. The Product Owner and Scrum Master are not counted as part of the Development Team size unless they are also doing Sprint work.

The Five Scrum Events

The Sprint is the heart of Scrum — a time-box of one month or less during which a "Done," usable, and potentially releasable product increment is created. Sprints have consistent lengths throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. During the Sprint, no changes are made that would endanger the Sprint Goal, quality does not decrease, scope may be clarified and renegotiated between the Product Owner and Development Team as more is learned, and the Sprint may be cancelled if the Sprint Goal becomes obsolete — only the Product Owner has the authority to cancel a Sprint.

Sprint Planning answers two questions: What can be delivered in the increment resulting from the upcoming Sprint? (The Development Team forecasts the Product Backlog items it will deliver, and the Scrum Team collaborates to craft the Sprint Goal.) And how will the work needed to deliver the increment be accomplished? (The Development Team decomposes the selected items into tasks of one day or less.) Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint, proportionally shorter for shorter Sprints. Only the Development Team can assess how much work it can take on — the Scrum Master ensures the event takes place and that the attendees understand its purpose.

The Daily Scrum is a 15-minute time-boxed event for the Development Team. It is held every day at the same time and place to reduce complexity. The classic three questions — what did I do yesterday that helped the Development Team meet the Sprint Goal, what will I do today to help the Development Team meet the Sprint Goal, and do I see any impediments that prevent me or the Development Team from meeting the Sprint Goal — are one common format, but the format is not mandated by the Scrum Guide. The purpose is for the Development Team to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The Scrum Master ensures the event is held but does not run the meeting — it is owned by the Development Team.

The Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed. The Scrum Team and stakeholders collaborate about what was done in the Sprint. Attendees include the Scrum Team and key stakeholders invited by the Product Owner. The Development Team demonstrates the work that was done and answers questions. The Product Owner discusses the Product Backlog as it stands and projects likely completion dates. The Sprint Review is time-boxed to a maximum of four hours for a one-month Sprint. A common mistake on the CSM assessment is confusing the Sprint Review (which focuses on the product increment and the backlog) with the Sprint Retrospective (which focuses on the team's process).

The Sprint Retrospective is the Scrum Team's opportunity to inspect itself and create a plan for improvements to be enacted during the next Sprint. It occurs after the Sprint Review and before the next Sprint Planning. The Scrum Team inspects how the last Sprint went with regards to people, relationships, process, and tools. It identifies what went well, what did not, and what improvements it will implement in the next Sprint. The Retrospective is time-boxed to a maximum of three hours for a one-month Sprint. The Scrum Master participates as a peer team member and ensures the event is positive and productive. At least one high-priority improvement should be added to the next Sprint Backlog as a formal commitment.

The Three Scrum Artifacts

The Product Backlog is an ordered list of everything known that might be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Backlog is never complete — it evolves as the product and the environment in which it will be used evolves. Items higher in the backlog are more refined, have more detail, and have smaller estimates. Product Backlog refinement (formerly "grooming") is the ongoing process of adding detail, estimates, and order to items — it consumes no more than 10% of the Development Team's capacity and is performed throughout the Sprint.

The Sprint Backlog consists of the Sprint Goal, the set of Product Backlog items selected for the Sprint, and a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast of the functionality that will be in the next increment and the work needed to deliver that functionality. The Sprint Backlog belongs to the Development Team — only the Development Team can change it during the Sprint. The Sprint Backlog is updated throughout the Sprint as work is learned.

The Increment is the sum of all the Product Backlog items completed during a Sprint combined with the value of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," meaning it meets the Scrum Team's shared Definition of Done. The increment must be in a usable condition regardless of whether the Product Owner decides to release it. Multiple increments may be created within a Sprint, and they must all meet the Definition of Done.

Key Scrum Concepts for the CSM Assessment

The Definition of Done (DoD) is a shared understanding of what it means for work to be complete. It ensures transparency and establishes a common understanding of when work is finished. A strong Definition of Done typically includes passing all automated tests, code review completed, documentation updated, no known critical defects, and the increment integrated into the main codebase. The Definition of Done is created by the Scrum Team if the organization does not provide one, and it must be understood by all team members. Items that do not meet the DoD are not included in the Sprint Review — they are not "done" and cannot be presented as a completed increment.

Empirical process control is the philosophical foundation of Scrum. It consists of three pillars: transparency (significant aspects of the process must be visible to those responsible for the outcome), inspection (Scrum users frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances), and adaptation (if an inspector determines that aspects of a process deviate outside acceptable limits and will result in an unacceptable product, the process or the material being processed must be adjusted). The five Scrum events are the formal opportunities for inspection and adaptation.

Velocity is the amount of work a Development Team completes during a Sprint, measured in story points (or whatever unit the team uses for estimation). Velocity is a planning tool — it tells the team approximately how much work it can commit to in a future Sprint based on past performance. Velocity is team-specific and should not be used to compare different teams. Burn-down charts plot remaining work (story points or tasks) against time remaining in the Sprint, showing whether the team is on track to meet its Sprint Goal. Burn-up charts plot work completed against total scope, making scope changes visible. Neither chart is mandated by the Scrum Guide — they are useful tools, not requirements.

Story point estimation and Planning Poker are covered on the CSM assessment. User stories follow the format "As a [type of user], I want [goal] so that [benefit]." Story points measure complexity, effort, and risk relative to other stories — they are deliberately not tied to hours because individual developer speed varies. Planning Poker uses Fibonacci-like sequences (1, 2, 3, 5, 8, 13, 20, 40, 100) to prevent anchoring: team members simultaneously reveal their estimates, discuss the reasons for disagreement, and re-estimate until consensus is reached. Relative sizing is the practice of estimating stories by comparing them to reference stories of known size rather than estimating absolute effort in hours.

How to Use the CSM Practice PDF

Print the PDF before your certification course if possible. Reviewing practice questions before the two-day training lets you arrive with context — when the instructor explains sprint planning, you will recognize the concepts rather than hearing them for the first time. After the course, work through the PDF again with fresh eyes. Questions you found difficult before the training will often make complete sense after two days of hands-on activities and discussion.

Pay special attention to questions about the boundaries between roles. The CSM assessment frequently presents scenarios designed to test whether you know who has authority over what. The Product Owner orders the backlog — not the Scrum Master, not a stakeholder, not a manager outside the team. The Development Team decides how to do the work — not the Product Owner, not the Scrum Master. The Scrum Master facilitates but does not control. If you keep these authority boundaries clear in your mind, a large category of scenario questions becomes straightforward.

Focus on the distinction between the Sprint Review and the Sprint Retrospective. Both happen at the end of the Sprint, and candidates frequently confuse them. The Sprint Review is about the product — what was built, what was not built, how the backlog should change going forward — and it includes stakeholders. The Sprint Retrospective is about the team and its process — how the team worked together, what tools and practices are working, and what the team will improve in the next Sprint — and it does not include stakeholders outside the Scrum Team.

Common CSM Assessment Mistakes

The most frequently missed question type on the CSM assessment involves who can do what. Many candidates who work in organizations where Scrum is implemented loosely — where the manager still assigns tasks, where the "Product Owner" is just a developer who writes tickets, or where Sprint Retrospectives are skipped — arrive with habits that contradict the Scrum Guide. The assessment tests the Scrum Guide, not the way Scrum is practiced at your company. Answer based on what the framework says, not what your organization does.

A second common error is misunderstanding the Product Owner's authority. Some candidates assume the Scrum Master or the team's technical lead has authority over the backlog because they are "more technical." According to the Scrum Guide, the Product Owner is the single accountable person for the Product Backlog, and the Development Team must respect the Product Owner's ordering of the backlog. The Scrum Master may coach the Product Owner on effective backlog management techniques, but the Scrum Master does not override or veto the Product Owner's decisions.

Third, candidates often confuse refinement with planning. Product Backlog refinement (grooming) is an ongoing background activity that happens throughout the Sprint — it consumes no more than 10% of the Development Team's capacity and is not a formal Scrum event. Sprint Planning is a formal Scrum event that occurs at the beginning of each Sprint. The two activities both involve discussing backlog items, but they are distinct in purpose, timing, and formality. Refinement prepares items for future Sprints; planning selects items and creates a plan for the current Sprint.

Beyond the CSM: What Comes Next

The CSM is the entry-level Scrum Alliance credential. The Advanced Certified ScrumMaster (A-CSM) requires CSM certification plus at least 12 months of Scrum Master work experience and completion of an advanced course. The Certified Scrum Professional — ScrumMaster (CSP-SM) requires A-CSM plus additional experience. On the Product Owner track, the Certified Scrum Product Owner (CSPO) is the counterpart to the CSM. At the highest level, the Certified Scrum Trainer (CST) and Certified Enterprise Coach (CEC) credentials indicate master-level Scrum knowledge and the ability to teach and coach organizations at scale. The PDF below prepares you for the first step — passing the CSM assessment with confidence.