CSM — Scrum Alliance Certified ScrumMaster Cheat Sheet

After this Cheat Sheet, use original practice questions to test decision-making, not just vocabulary. For each missed question, identify which Scrum rule or value you overlooked.

A useful practice pattern:

1. Complete a short topic drill on accountabilities, events, or artifacts.
2. Review detailed explanations for every missed or guessed question.
3. Write down the decision rule behind the correct answer.
4. Take a mixed question bank set to practice switching topics.
5. Use mock exams to build timing, confidence, and scenario-recognition.

Focus especially on scenario questions where several answers sound reasonable. The best answer usually preserves Scrum accountabilities, transparency, self-management, and inspection/adaptation.

Scrum Values in Exam Scenarios

Scrum values

The Scrum values guide behavior. In exam scenarios, the best answer often supports one or more of these values.

Product Owner Cheat Sheet

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 Cheat Sheet

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 Cheat Sheet

Scrum Team accountabilities

Scrum has one Scrum Team with three accountabilities: Product Owner, Scrum Master, and Developers. Avoid thinking of these as traditional hierarchy roles.

Product Owner

The Product Owner is accountable for maximizing product value and for effective Product Backlog management.

High-yield Product Owner rules:

• The Product Owner orders the Product Backlog.
• The Product Owner is one person, not a committee.
• Stakeholders may influence priorities, but the Product Owner remains accountable.
• The Product Owner clarifies value, goals, and backlog items.
• The Product Owner should be available to the Scrum Team.
• Product Backlog ordering should consider value, risk, dependencies, learning, and stakeholder needs.

Common traps:

• Trap: The Scrum Master prioritizes the Product Backlog. Better: The Product Owner is accountable for ordering it.

• Trap: A committee votes on Product Backlog order. Better: The Product Owner may consult many people, but one Product Owner is accountable.

• Trap: The Product Owner assigns tasks to Developers. Better: Developers self-manage their work.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined by the Scrum framework. The Scrum Master serves the Scrum Team and the organization by coaching, teaching, facilitating, and helping remove impediments.

High-yield Scrum Master rules:

• The Scrum Master is not the project manager.

• The Scrum Master does not assign tasks.

• The Scrum Master does not own delivery status on behalf of the Developers.

• The Scrum Master helps the team understand and use Scrum.

• The Scrum Master protects empiricism, not comfort.

• The Scrum Master helps remove impediments but does not become the team’s personal assistant.

• The Scrum Master should coach the team to solve problems when appropriate.

• Trap: The Scrum Master tells each Developer what to do next. Better: Developers self-manage; the Scrum Master coaches the team.

• Trap: The Scrum Master cancels the Sprint because progress is poor. Better: Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete.

• Trap: The Scrum Master updates the Sprint Backlog for the team. Better: Developers own the Sprint Backlog.

Developers

Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint. “Developer” does not only mean software programmer; it means anyone doing the work of creating the product Increment.

High-yield Developer rules:

• Developers self-manage.

• Developers decide how to turn Product Backlog items into a Done Increment.

• Developers own estimates when estimates are used.

• Developers adapt the Sprint Backlog during the Sprint.

• Developers are accountable for quality and the Definition of Done.

• Trap: The Product Owner decides how Developers should implement the work. Better: The Product Owner explains value and priorities; Developers decide how.

• Trap: The Scrum Master assigns tasks to improve efficiency. Better: Developers choose and coordinate their work.

• Trap: A manager changes the Sprint Backlog directly. Better: Developers manage the Sprint Backlog; outside requests should be handled transparently through Scrum accountabilities.

Sprint Planning: Three Questions

Daily Scrum: What It Is and Is Not

Scrum events

Scrum events create a cadence for inspection and adaptation. They are not status meetings for management.

Sprint

The Sprint is the heartbeat of Scrum. It is a fixed-length event of one month or less during which the Scrum Team creates value.

Remember:

• A new Sprint starts immediately after the previous Sprint ends.

• The Sprint contains all other Scrum events.

• The Sprint Goal provides focus.

• Scope may be clarified and renegotiated as more is learned, as long as the Sprint Goal is not endangered.

• Quality does not decrease during the Sprint.

• A Sprint may be canceled if the Sprint Goal becomes obsolete.

• Only the Product Owner has the authority to cancel the Sprint.

• Extending the Sprint to finish incomplete work

• Shortening quality practices to meet a date

• Treating the Sprint as a mini-waterfall phase

• Allowing random work to enter the Sprint without considering the Sprint Goal

Sprint Planning

Sprint Planning answers three key questions:

1. Why is this Sprint valuable?
2. What can be Done this Sprint?
3. How will the chosen work get Done?

• Trap: Product Owner dictates exactly how much work Developers must accept. Better: Developers select the amount of work they believe they can complete.

• Trap: Sprint Planning is only task assignment. Better: It is about goal, value, selected work, and an initial plan.

• Trap: The Sprint Goal is just a list of backlog items. Better: It is an objective that gives coherence and flexibility.

Daily Scrum

The Daily Scrum is a short event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed.

• It is for Developers.

• It is not a status report to the Scrum Master.

• The structure can vary as long as the event achieves its purpose.

• The Scrum Master ensures the event occurs, but the Developers conduct it.

• The Product Owner or Scrum Master participates as a Developer only if they are actively working on Sprint Backlog items.

• Reporting to the Scrum Master

• Waiting until the Daily Scrum to solve urgent problems

• Discussing every detail instead of focusing on adaptation

• Treating the three traditional questions as mandatory

Sprint Review

The Sprint Review inspects the outcome of the Sprint and determines future adaptations. The Scrum Team and stakeholders discuss what was accomplished, what changed, and what should happen next.

• It is not merely a demo.

• Stakeholder feedback matters.

• The Product Backlog may be adapted.

• The Increment is inspected against goals, market changes, user needs, and stakeholder input.

• It is collaborative, not a formal approval gate.

• Treating the Sprint Review as a sign-off meeting

• Hiding unfinished work or quality problems

• Excluding stakeholders

• Showing work that is not Done as if it were complete

Sprint Retrospective

The Sprint Retrospective is the Scrum Team’s opportunity to inspect itself and improve. It focuses on people, interactions, processes, tools, and Definition of Done improvements.

• It happens after the Sprint Review and before the next Sprint Planning.

• The whole Scrum Team participates.

• The outcome should include useful improvements.

• It is not a blame session.

• Improvements should be practical and actionable.

• Skipping the retrospective because the team is busy

• Only discussing technical issues and ignoring collaboration

• Creating too many improvement actions

• Letting the Scrum Master “own” all improvements

Product Backlog

Sprint Backlog

Increment and Definition of Done

Scrum artifacts and commitments

Scrum artifacts make work and value transparent. Each artifact has a commitment that improves transparency and focus.

Product Backlog

The Product Backlog is an ordered, emergent list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

High-yield points:

• The Product Owner is accountable for Product Backlog management.

• The Product Backlog is never “complete” in a complex environment.

• Product Backlog items may include features, fixes, enhancements, experiments, technical work, and learning needs.

• Product Backlog refinement is ongoing work, not a formal Scrum event.

• Items near the top are usually better understood and more ready for selection.

• Treating the Product Backlog as a fixed scope contract

• Allowing multiple competing Product Backlogs for one product

• Assuming every Product Backlog item must be fully detailed far in advance

• Confusing backlog ordering with simple priority ranking only

Product Goal

The Product Goal describes a future state of the product that can serve as a target for the Scrum Team.

• It provides long-term direction.
• The Product Backlog emerges to define what will fulfill the Product Goal.
• The Product Goal helps connect Sprint-level decisions to broader value.

Sprint Backlog

The Sprint Backlog contains:

• The Sprint Goal

• Product Backlog items selected for the Sprint

• The plan for delivering them

• Developers own the Sprint Backlog.

• The Sprint Backlog is adapted throughout the Sprint.

• The Sprint Backlog is a plan, not a fixed task contract.

• Changes should support the Sprint Goal.

• Product Owner changes the Sprint Backlog directly

• Scrum Master assigns Sprint Backlog tasks

• Team refuses to update the Sprint Backlog after learning new information

• Treating Sprint Backlog completion as more important than Sprint Goal achievement

Sprint Goal

The Sprint Goal is the single objective for the Sprint. It creates focus and allows flexibility.

Good Sprint Goal thinking:

• It explains why the Sprint matters.
• It helps the team make tradeoff decisions.
• It is not simply “finish all selected backlog items.”
• It should remain stable enough to guide the Sprint.

Increment

An Increment is a concrete stepping stone toward the Product Goal. Multiple Increments may be created within a Sprint, and the sum of Increments must be usable.

• An Increment must meet the Definition of Done.

• Work cannot be considered part of the Increment unless it is Done.

• A Done Increment is usable.

• Release is a business decision; Done does not always mean immediately released.

• Calling work “Done” when testing, integration, documentation, or required quality work remains

• Treating “almost done” as part of the Increment

• Confusing “released” with “releasable”

• Letting separate teams use incompatible quality standards for the same product

Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

• It creates transparency about quality and completeness.

• It applies to the Increment.

• If organizational standards exist, they are part of the Definition of Done.

• The Scrum Team can improve the Definition of Done over time.

• For multiple Scrum Teams working on the same product, they should share a common Definition of Done as a minimum standard.

• Confusing Definition of Done with acceptance criteria

• Letting each Developer define “done” individually

• Lowering the Definition of Done to meet a deadline

• Treating undone work as a carryover detail rather than a transparency issue

Change During a Sprint

Impediment Handling

Scrum decision rules

Use these quick rules when answering scenario questions.

Product Backlog refinement

Product Backlog refinement is the ongoing activity of adding detail, estimates, ordering, and clarity to Product Backlog items.

• Refinement is not a formal Scrum event.

• The Scrum Team decides how to do refinement.

• The Product Owner is accountable for Product Backlog management.

• Developers contribute by clarifying technical work, risks, dependencies, and estimates.

• Refinement helps make Sprint Planning more effective.

• Assuming refinement replaces Sprint Planning

• Expecting the Product Owner to fully refine everything alone

• Refining the entire Product Backlog in detail far ahead of time

• Treating estimates as commitments

Sprint cancellation

Sprint cancellation is rare. A Sprint is canceled only if the Sprint Goal becomes obsolete. The Product Owner has the authority to cancel the Sprint.

Scaling and multiple teams

For basic CSM review, focus first on one Scrum Team. Still, know these principles for multiple-team scenarios:

• Multiple Scrum Teams may work on one product.
• There should be one Product Backlog for the product.
• There should be one Product Owner accountable for the product.
• Teams working on the same product should share a common Definition of Done as a minimum.
• Integration and transparency become more important, not less.
• Adding teams does not remove the need for empiricism, self-management, and clear product ownership.

Common trap:

• Creating separate Product Owners and Product Backlogs for each component team without maintaining one coherent product direction.

Definition of Done vs Acceptance Criteria

Product Owner vs Scrum Master

Definition of Done vs acceptance criteria

This distinction is frequently tested in scenario form.

Decision rule:

• If the question is about overall quality and whether work is part of the Increment, think Definition of Done.
• If the question is about specific behavior or conditions for one Product Backlog item, think acceptance criteria.

High-yield comparison table

Coaching

Coaching helps people improve their own thinking and behavior.

• Asking Developers how they want to adapt their plan
• Helping the Product Owner think through Product Backlog ordering
• Helping stakeholders understand Scrum boundaries
• Encouraging the team to address recurring impediments
• Supporting self-management instead of solving every problem personally

Servant leadership / true leadership

In Scrum, leadership is shown by service, accountability, and enabling others.

Good Scrum Master behavior:

• Teaches Scrum clearly
• Helps the organization remove barriers
• Encourages transparency even when information is uncomfortable
• Protects the team’s ability to focus without isolating it from stakeholders
• Helps people understand why Scrum events and artifacts matter

Poor Scrum Master behavior:

• Becomes the team secretary
• Approves or rejects technical work
• Controls all communication
• Acts as a buffer that prevents Product Owner and Developers from collaborating
• Makes all decisions to keep the team moving quickly