This independent Quick Reference is for candidates preparing for the Scrum Alliance Certified ScrumMaster (CSM) exam, code CSM, from Scrum Alliance. Use it to review Scrum accountabilities, events, artifacts, commitments, Scrum Master service patterns, and high-yield exam distinctions.
Scrum Framework at a Glance
| Element | What to remember for CSM |
|---|
| Scrum purpose | A lightweight framework for generating value through adaptive solutions for complex problems. |
| Theory base | Empiricism and lean thinking. Decisions are based on observed reality, not detailed upfront prediction. |
| Pillars | Transparency, inspection, adaptation. |
| Values | Commitment, focus, openness, respect, courage. |
| Scrum Team | One Product Owner, one Scrum Master, and Developers. No subteams or hierarchies inside the Scrum Team. |
| Events | Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. |
| Artifacts | Product Backlog, Sprint Backlog, Increment. |
| Artifact commitments | Product Goal, Sprint Goal, Definition of Done. |
| Core rhythm | Each Sprint creates at least one usable Increment that meets the Definition of Done. |
| Scrum Master stance | Servant-leader/true-leader behavior: teach, coach, facilitate, remove impediments, improve transparency, and help people use Scrum correctly. |
Scrum Theory and Values
Empiricism, Lean Thinking, and the Three Pillars
| Concept | Exam meaning | Common trap |
|---|
| Empiricism | Knowledge comes from experience; decisions are based on what is known and observed. | Treating a long upfront plan as more reliable than inspection and adaptation. |
| Lean thinking | Reduce waste and focus on essentials. | Adding meetings, handoffs, approvals, or documentation that do not improve value or transparency. |
| Transparency | Important information is visible and understood by those inspecting it. | Hiding undone work, unclear “done,” inflated progress reports. |
| Inspection | Frequent checking of artifacts and progress toward goals. | Inspection is not micromanagement; it should reveal reality. |
| Adaptation | Adjust process, plans, backlog, or approach when inspection shows deviation or new learning. | Inspecting without changing anything. |
Scrum Values in Exam Scenarios
| Value | Practical behavior |
|---|
| Commitment | Commit to goals, professionalism, learning, and supporting the Scrum Team. Not a promise to deliver fixed scope regardless of learning. |
| Focus | Focus primarily on Sprint work and progress toward the Sprint Goal. |
| Openness | Make work, impediments, risks, and progress visible. |
| Respect | Treat people as capable, independent professionals. |
| Courage | Surface hard truths, challenge wasteful practices, and do the right thing for product value and quality. |
Scrum Accountabilities
Scrum uses accountabilities, not traditional command-and-control roles. A high-yield CSM pattern: choose the answer that preserves the correct accountability and helps the Scrum Team become more self-managing.
| Accountability | Accountable for | Key exam points |
|---|
| Product Owner | Maximizing product value and effective Product Backlog management. | One Product Owner, not a committee. May delegate work, but remains accountable. Owns ordering of the Product Backlog. |
| Scrum Master | Establishing Scrum as defined by the Scrum Guide and improving Scrum Team effectiveness. | Does not assign tasks, manage Developers, own delivery, or act as project manager. Coaches, facilitates, teaches, and removes impediments. |
| Developers | Creating any aspect of a usable Increment each Sprint. | Self-managing, cross-functional, create the Sprint plan, adapt the Sprint Backlog, uphold quality, and hold each other accountable. |
| Scrum Team | Creating value each Sprint. | Small enough to be nimble and large enough to complete significant work; typically 10 or fewer people. |
Product Owner Quick Reference
| Product Owner responsibility | What it means |
|---|
| Develop and communicate the Product Goal | The Product Goal gives the Scrum Team a longer-term product objective. |
| Create and communicate Product Backlog items | PBIs must be understandable enough for planning and refinement. |
| Order Product Backlog items | Ordering reflects value, risk, dependencies, learning, and strategy. |
| Ensure Product Backlog transparency | The backlog must be visible, understood, and clear enough to support decisions. |
| Maximize value | The Product Owner decides what is most valuable; stakeholders influence but do not overrule the PO directly. |
Exam traps
- The Product Owner may delegate backlog work, but accountability stays with the Product Owner.
- Stakeholders do not directly assign work to Developers.
- A Product Owner who lacks authority is an impediment the Scrum Master should help address.
- The Product Owner is one person, not a steering committee.
Scrum Master Quick Reference
| Service area | Scrum Master actions |
|---|
| To the Scrum Team | Coach self-management and cross-functionality; help the team focus on high-value Increments; remove impediments; ensure events are positive, productive, and within timebox. |
| To the Product Owner | Help with Product Goal definition, Product Backlog management, empirical planning, and stakeholder collaboration. |
| To the organization | Lead, train, and coach Scrum adoption; help people understand empirical product development; remove organizational barriers. |
Scrum Master does not
- Assign tasks.
- Decide how Developers do the work.
- Own the Product Backlog.
- Approve or reject completed work as a phase gate.
- Force velocity targets.
- Serve as the team’s status reporter to management.
- Protect the team by hiding information.
Developers Quick Reference
| Developer accountability | What to know |
|---|
| Create the Sprint Backlog plan | Developers decide how to turn selected Product Backlog items into an Increment. |
| Instill quality | Developers follow the Definition of Done and improve engineering or delivery practices. |
| Adapt daily | Developers adjust the Sprint Backlog as they learn. |
| Hold each other accountable | Professional accountability replaces task assignment by a manager. |
| Cross-functional work | The team has all skills needed to create a usable Increment. Individuals may specialize, but accountability is shared. |
Scrum Events and Timeboxes
Timeboxes are maximum durations. Shorter Sprints usually have shorter events. A new Sprint starts immediately after the previous Sprint ends.
| Event | Timebox | Participants | Purpose | Output / result | CSM traps |
|---|
| Sprint | One month or less | Scrum Team | Container for all Scrum events and work needed to create value. | Usable Increment; progress toward Product Goal. | A Sprint is not a mini-waterfall phase. Quality does not decrease. |
| Sprint Planning | Max 8 hours for a one-month Sprint | Whole Scrum Team; others may be invited for advice | Decide why the Sprint is valuable, what can be done, and how it will be done. | Sprint Goal, selected PBIs, plan for delivery; together these form the Sprint Backlog. | Product Owner proposes value; Developers forecast capacity and decide what they can do. |
| Daily Scrum | 15 minutes | Developers; PO/SM participate if actively working as Developers | Inspect progress toward Sprint Goal and adapt the Sprint Backlog. | Updated plan for the next working day. | Not a status meeting for the Scrum Master. No required “three questions.” |
| Sprint Review | Max 4 hours for a one-month Sprint | Scrum Team and stakeholders | Inspect the outcome of the Sprint and adapt future direction. | Feedback and Product Backlog adaptations. | Not a formal approval gate or demo-only meeting. |
| Sprint Retrospective | Max 3 hours for a one-month Sprint | Scrum Team | Inspect how the last Sprint went regarding people, interactions, processes, tools, and Definition of Done. | Improvement actions for quality and effectiveness. | Not a blame session; improvement work may enter the next Sprint Backlog. |
Sprint Planning: Three Questions
| Question | Main accountability | Exam cue |
|---|
| Why is this Sprint valuable? | Product Owner proposes how value could increase; Scrum Team creates Sprint Goal. | Sprint Goal gives coherence and flexibility. |
| What can be Done this Sprint? | Developers select work through discussion with Product Owner. | The Product Owner does not force scope into the Sprint. |
| How will the chosen work get Done? | Developers plan the work. | Scrum Master may facilitate, but Developers own the plan. |
Daily Scrum: What It Is and Is Not
| Daily Scrum is | Daily Scrum is not |
|---|
| For Developers to inspect progress toward the Sprint Goal. | A reporting session to the Scrum Master. |
| A 15-minute event at the same time and place each working day. | The only time Developers can adjust their plan. |
| A chance to adapt the Sprint Backlog. | A problem-solving meeting for every detail. |
| Flexible in format if it helps progress toward the Sprint Goal. | Required to use “yesterday/today/blockers.” |
Artifacts and Commitments
| Artifact | Commitment | Owner / accountability | Purpose | High-yield distinction |
|---|
| Product Backlog | Product Goal | Product Owner accountable | Ordered, emergent list of what is needed to improve the product. | Product Backlog is never “complete”; it evolves as learning occurs. |
| Sprint Backlog | Sprint Goal | Developers accountable | Plan by and for Developers: Sprint Goal, selected PBIs, and plan to deliver. | It changes during the Sprint as Developers learn. |
| Increment | Definition of Done | Scrum Team accountable; Developers create | Concrete stepping stone toward the Product Goal. | Only work meeting the Definition of Done is part of the Increment. |
Product Backlog
| Concept | CSM exam meaning |
|---|
| Ordered | Ordered by the Product Owner based on value, risk, dependencies, learning, and strategy. |
| Emergent | Changes as product understanding changes. |
| Transparent | Visible and understood enough to support decisions. |
| Refinement | Ongoing activity of breaking down and clarifying items. Not a formal Scrum event. |
| Product Goal | Long-term objective for the Scrum Team; the Product Backlog commitment. |
Sprint Backlog
| Concept | CSM exam meaning |
|---|
| Owned by Developers | Developers create and adapt the plan. |
| Flexible scope | Selected work may be clarified and renegotiated with the Product Owner if the Sprint Goal remains intact. |
| Focused by Sprint Goal | The Sprint Goal is the single objective for the Sprint. |
| Updated daily | The Sprint Backlog should reflect current learning and remaining work. |
Increment and Definition of Done
| Concept | CSM exam meaning |
|---|
| Increment | Usable, additive work that meets the Definition of Done. |
| Potentially releasable | The Increment is in a usable state; release timing is a business decision. |
| Definition of Done | Formal description of the state of the Increment when it meets quality measures. |
| Undone work | Work that does not meet the Definition of Done is not part of the Increment. |
| Shared DoD | If multiple Scrum Teams work on the same product, they must use the same Definition of Done. |
| Organization standard | If the organization has a Definition of Done standard, the Scrum Team must follow it at minimum. |
Commitment Distinctions
| Commitment | Attached to | Answers | Changes when |
|---|
| Product Goal | Product Backlog | “Where are we trying to take the product?” | Product strategy changes or the goal is achieved/replaced. |
| Sprint Goal | Sprint Backlog | “Why is this Sprint valuable?” | Should remain stable enough to guide the Sprint; if obsolete, Product Owner may cancel the Sprint. |
| Definition of Done | Increment | “What quality state must work meet to count as done?” | Improved as quality understanding matures; should not be weakened to claim progress. |
High-Yield Decision Tables
What Should the Scrum Master Do Next?
| Scenario | Best Scrum Master response | Avoid |
|---|
| Developers ask the Scrum Master to assign tasks. | Coach Developers to self-manage and select work themselves. | Assigning tasks to “help them move faster.” |
| Daily Scrum becomes a status report to the Scrum Master. | Teach the purpose: Developers inspect progress toward the Sprint Goal and adapt the plan. | Collecting updates and reporting them upward. |
| Product Owner orders too much work into the Sprint. | Facilitate discussion; Developers decide what they can forecast for the Sprint. | Letting the PO commit the Developers to fixed scope. |
| Stakeholder pressures Developers directly for new work. | Coach stakeholders to work through the Product Owner and maintain Product Backlog transparency. | Blocking all stakeholder contact or accepting side work. |
| PBI is not Done by Sprint end. | Do not include it in the Increment; return/reorder remaining work in Product Backlog as appropriate; inspect causes. | Calling it “almost done” or releasing it anyway. |
| Team repeatedly misses the Sprint Goal. | Improve transparency, inspect planning/refinement/impediments, coach better forecasting and focus. | Punishing the team or forcing velocity targets. |
| Retrospectives produce no action. | Facilitate concrete, visible improvement experiments. | Treating the retrospective as optional. |
| Manager wants individual performance metrics from Scrum events. | Educate on Scrum Team accountability and risks of misusing metrics. | Ranking Developers by story points or tasks completed. |
| Product Owner is unavailable. | Coach the PO and organization on PO accountability and decision latency. | Having the Scrum Master become the Product Owner. |
| Organization demands predictive certainty. | Teach empirical planning, transparency, incremental delivery, and evidence-based forecasting. | Pretending Scrum guarantees fixed scope/fixed date certainty. |
Change During a Sprint
| Change type | Scrum response |
|---|
| Clarification of selected PBI | Product Owner and Developers collaborate; Developers adjust Sprint Backlog plan. |
| New stakeholder request | Product Owner considers it for Product Backlog ordering. It does not automatically enter the current Sprint. |
| Change that does not endanger Sprint Goal | Product Owner and Developers may negotiate scope. |
| Change that makes Sprint Goal obsolete | Product Owner may cancel the Sprint. |
| Quality pressure | Quality does not decrease. Work must meet the Definition of Done to be part of the Increment. |
Impediment Handling
| Impediment | First Scrum Master move |
|---|
| Team lacks a skill needed for Increment | Coach cross-functionality; help remove organizational constraints; support learning. |
| External dependency blocks progress | Make it transparent, facilitate resolution, escalate only when needed. |
| Tooling or environment prevents Done work | Help remove the impediment; make cost of delay visible. |
| Conflict inside Scrum Team | Facilitate constructive conversation; coach respect, openness, and accountability. |
| Product Owner cannot make decisions | Coach PO and stakeholders; expose impact on value and flow. |
| Organization bypasses Scrum accountabilities | Teach Scrum, coach leaders, and reinforce clear decision rights. |
Scrum vs Traditional Project Management Traps
| Traditional assumption | Scrum exam correction |
|---|
| Scrum Master is the project manager. | Scrum Master is accountable for Scrum effectiveness, not command-and-control delivery management. |
| Scope is fixed at Sprint Planning. | Sprint Goal is stable; scope may be clarified and negotiated. |
| Daily Scrum is a status meeting. | It is a planning and inspection event for Developers. |
| Sprint Review is sign-off. | It is inspection and adaptation with stakeholders. |
| Retrospective is a lessons-learned meeting at the end of a project. | It occurs every Sprint and drives continuous improvement. |
| Velocity is a commitment. | Velocity is an optional forecasting aid, not a promise or performance target. |
| A separate testing phase proves quality. | Quality is built in; Done work meets the Definition of Done each Sprint. |
| Change control board approves all changes. | Product Owner orders the Product Backlog; Scrum uses empirical adaptation. |
Optional Practices Often Confused With Scrum Rules
These practices may be useful, but they are not mandatory Scrum framework elements unless your organization adopts them.
| Practice | Scrum status | Exam distinction |
|---|
| User stories | Optional format for Product Backlog items. | Scrum requires Product Backlog items, not a specific template. |
| Story points | Optional estimation technique. | Developers who do the work are best positioned to estimate. |
| Velocity | Optional forecasting metric. | Do not use as a target to pressure the team. |
| Burndown/burnup charts | Optional transparency tools. | Useful only if they improve inspection and adaptation. |
| Definition of Ready | Optional working agreement. | Should not become a rigid phase gate that blocks learning. |
| Sprint 0 | Not a Scrum event. | Prefer creating value in real Sprints; setup work should be transparent. |
| Release Sprint | Not required by Scrum. | Each Increment should be usable; release is a business decision. |
| Scrum of Scrums | Scaling practice, not a core Scrum event. | Multiple teams on one product should share Product Goal, Product Backlog, and Product Owner. |
Product Backlog Refinement
| Point | CSM-ready interpretation |
|---|
| Purpose | Increase Product Backlog clarity so upcoming work can be understood and planned. |
| Timing | Ongoing activity, not a prescribed Scrum event. |
| Participants | Product Owner and Developers; others may help with domain or technical knowledge. |
| Output | Smaller, clearer, better-ordered Product Backlog items. |
| Estimation | Developers are responsible for sizing/estimating because they do the work. |
| Trap | Refinement does not guarantee all future scope is known or fixed. |
Sprint Cancellation
| Question | Answer |
|---|
| Who can cancel a Sprint? | Product Owner. |
| When should it happen? | When the Sprint Goal becomes obsolete. |
| Is cancellation common? | It should be rare because Sprints are short. |
| What happens to completed Done work? | It is reviewed as part of the usable Increment if it meets the Definition of Done. |
| What happens to incomplete work? | It returns to the Product Backlog as appropriate and is re-estimated/reordered if needed. |
Scaling and Multiple Scrum Teams
| Situation | Scrum guidance |
|---|
| Scrum Team is too large | Consider reorganizing into multiple cohesive Scrum Teams. |
| Multiple teams on same product | They share the same Product Goal, Product Backlog, and Product Owner. |
| Multiple teams creating one Increment | Work must integrate into one usable Increment that meets a shared Definition of Done. |
| Coordination problem | Prefer transparency, shared goals, and direct collaboration over heavy management layers. |
Exam Answer Patterns
When two answers look plausible, favor the one that:
- Preserves Scrum accountabilities.
- Increases transparency before prescribing a solution.
- Uses inspection and adaptation.
- Coaches self-management instead of commanding.
- Protects quality and the Definition of Done.
- Focuses on product value, not task completion.
- Uses Scrum events for their intended purpose.
- Removes impediments without taking over the team’s work.
- Helps the Product Owner, Developers, and stakeholders collaborate directly.
- Avoids adding unnecessary process, approval gates, or status reporting.
Fast Comparison Tables
Done vs Accepted vs Released
| Term | Meaning |
|---|
| Done | Meets the Definition of Done and is part of the Increment. |
| Accepted | Product Owner/stakeholders agree it satisfies expectations or acceptance criteria. Acceptance does not replace the Definition of Done. |
| Released | Made available to users/customers. A Done Increment may be released before, at, or after Sprint end depending on business decision. |
Definition of Done vs Acceptance Criteria
| Item | Applies to | Purpose |
|---|
| Definition of Done | Increment / all work counted as Done | Shared quality standard and transparency baseline. |
| Acceptance criteria | Specific Product Backlog item | Clarify item-specific expectations. |
| Sprint Goal | Sprint | Explains why the Sprint is valuable. |
| Product Goal | Product Backlog | Guides longer-term product direction. |
Product Owner vs Scrum Master
| Decision / activity | Product Owner | Scrum Master |
|---|
| Product Backlog ordering | Accountable | Coaches effective backlog management. |
| Product value decisions | Accountable | Facilitates transparency and collaboration. |
| Scrum process effectiveness | Collaborates | Accountable. |
| Stakeholder collaboration | Leads product conversation | Facilitates and removes barriers. |
| Sprint scope negotiation | Collaborates with Developers | Facilitates if helpful. |
| Task assignment | Does not assign | Does not assign. |
Common CSM Traps Checklist
- Scrum has three accountabilities, five events, three artifacts, and three artifact commitments.
- The Sprint is one month or less.
- Daily Scrum is 15 minutes and is for Developers.
- The Sprint Review is not a sign-off gate.
- The Sprint Retrospective is for process, people, tools, interactions, and quality improvement.
- The Product Owner owns Product Backlog ordering and value maximization.
- The Scrum Master teaches, coaches, facilitates, and removes impediments; they do not manage the team.
- Developers own the Sprint Backlog and decide how work is done.
- Only work meeting the Definition of Done is part of the Increment.
- A Done Increment is usable; release timing is separate.
- Quality does not decrease during a Sprint.
- The Product Owner may cancel a Sprint if the Sprint Goal becomes obsolete.
- Velocity, story points, user stories, burndowns, and Definition of Ready are optional practices, not core Scrum rules.
- Scrum is designed for complexity; it relies on empiricism, not predictive certainty.
Final Review Drill
Before exam practice, be able to answer these without notes:
- Who is accountable for Product Backlog ordering?
- Who creates and owns the Sprint Backlog plan?
- What are the three parts of the Sprint Backlog?
- What makes work part of the Increment?
- What is the purpose of the Daily Scrum?
- What is inspected at Sprint Review versus Sprint Retrospective?
- What should a Scrum Master do when managers bypass the Product Owner?
- What happens when a Sprint Goal becomes obsolete?
- Which Scrum practices are required, and which are merely common agile techniques?
- How do transparency, inspection, and adaptation show up in each Scrum event?
Next step: use this Quick Reference to drill scenario questions, especially Scrum Master “what should you do next?” items, then review every missed question against the relevant accountability, event, artifact, or commitment.