PSM-AI — Scrum.org Professional Scrum Master - AI Essentials Quick Reference
Compact Scrum.org PSM-AI quick reference covering Scrum accountabilities, AI-assisted Scrum events, prompt patterns, risks, and exam traps.
How to Use This Quick Reference
This Quick Reference supports independent preparation for the Scrum.org Professional Scrum Master - AI Essentials (PSM-AI) exam code PSM-AI. Use it to connect Scrum fundamentals with practical AI use by a Scrum Master.
High-yield exam mindset:
- AI is a tool, not a Scrum accountability. Product Owner, Scrum Master, Developers, and Scrum Team remain accountable.
- Empiricism still rules. AI-generated predictions, summaries, and drafts must be inspected and validated.
- Scrum events are not status ceremonies. AI should support transparency, inspection, and adaptation, not replace collaboration.
- Quality is not optional. AI-generated code, tests, documentation, requirements, or analysis must satisfy the Definition of Done and team standards.
- Scrum Master stance matters. Coach, facilitate, teach, and remove impediments. Do not use AI to command, police, or bypass self-management.
PSM-AI Core Mental Model
| Area | Exam-ready meaning | AI-enabled application | Common trap |
|---|---|---|---|
| Scrum theory | Scrum is founded on empiricism and lean thinking | Use AI to reveal patterns, summarize evidence, or generate options | Treating AI output as truth without inspection |
| Accountability | Humans remain accountable for outcomes and decisions | AI drafts or recommends; Scrum accountabilities decide | Saying “the AI decided” |
| Transparency | Work, progress, quality, and assumptions must be visible | Label AI-generated content, expose sources, assumptions, confidence, and gaps | Hiding AI use or presenting unsupported output as fact |
| Inspection | Scrum Team and stakeholders inspect artifacts, progress, and results | AI can detect anomalies, summarize feedback, or compare options | Replacing human inspection with automated reporting |
| Adaptation | Scrum Teams adjust based on inspection | AI can suggest adaptations or experiments | Letting AI change Sprint scope, goals, or priorities automatically |
| Self-management | Scrum Teams choose how to do their work | AI can support planning, learning, and collaboration | Using AI dashboards to micromanage individuals |
| Professionalism | Scrum Master helps the team use Scrum effectively | Coach responsible AI use, working agreements, and validation | Becoming the “AI tool administrator” instead of serving Scrum effectiveness |
Scrum Accountabilities With AI
| Accountability | Owns / is accountable for | AI can help with | AI must not replace |
|---|---|---|---|
| Product Owner | Maximizing product value; Product Goal; Product Backlog ordering | Draft PBIs, cluster stakeholder feedback, analyze market signals, suggest value/risk tradeoffs | Product decisions, ordering, value judgment, stakeholder accountability |
| Scrum Master | Scrum effectiveness; coaching, facilitation, teaching, impediment removal | Prepare facilitation options, detect process patterns, generate coaching questions, summarize impediments | Leadership stance, coaching judgment, conflict handling, accountability for Scrum effectiveness |
| Developers | Creating a usable Increment each Sprint; Sprint Backlog; quality | Generate tests, code suggestions, design options, documentation drafts, defect analysis | Technical ownership, quality decisions, Done, Sprint forecast |
| Scrum Team | Delivering valuable, useful Increments; creating and sustaining Scrum artifacts | Improve transparency and learning across product and process data | Collective ownership, collaboration, adaptation |
| Stakeholders | Provide feedback, context, needs, constraints | AI can summarize themes and sentiment from feedback | Direct Product Backlog control or bypassing Product Owner accountability |
Empiricism, Scrum Values, and AI
Three Pillars of Empiricism
| Pillar | What it means in Scrum | AI use that supports it | AI use that weakens it |
|---|---|---|---|
| Transparency | The real state of work and product is visible | AI-generated summaries cite inputs, assumptions, and uncertainty | Synthetic summaries hide missing data, risk, or defects |
| Inspection | Artifacts and progress are frequently examined | AI highlights trends, anomalies, duplicated PBIs, test gaps | Team accepts AI analysis without review |
| Adaptation | Adjust quickly when deviations are found | AI proposes experiments or options after inspection | AI automatically changes priorities, scope, or team behavior |
Scrum Values Applied to AI
| Scrum Value | AI-aware behavior | Exam trap |
|---|---|---|
| Commitment | Use AI to support Sprint Goal focus and product outcomes | Commit to AI-generated forecasts as guarantees |
| Focus | Reduce noise, summarize signals, clarify goals | Let AI create excessive analysis or distract from the Sprint Goal |
| Openness | Disclose AI use, uncertainty, risks, and assumptions | Hide AI-generated content from the team or stakeholders |
| Respect | Use AI to support people, not rank or shame them | Individual productivity surveillance from AI analytics |
| Courage | Challenge unsupported AI output and unsafe usage | Accept AI answers because they sound confident |
Scrum Events: AI-Enabled but Human-Owned
| Event | Purpose | AI may assist by | Correct Scrum Master stance | Avoid |
|---|---|---|---|---|
| Sprint | Container for all other events; creates focus on Sprint Goal | Monitor risks, summarize progress signals, surface impediments | Protect empirical learning and focus | Treat Sprint as an AI-managed workflow |
| Sprint Planning | Establish why the Sprint is valuable, what can be Done, and how work will be done | Summarize Product Backlog items, propose Sprint Goal wording, identify dependencies, analyze capacity scenarios | Facilitate shared understanding; ensure Developers forecast work | Let AI assign work or set Sprint commitment |
| Daily Scrum | Developers inspect progress toward Sprint Goal and adapt Sprint Backlog | Summarize board changes, flag blockers, show trend data | Coach Developers to own the event | Turn it into AI-generated status reporting for managers |
| Sprint Review | Inspect Increment and adapt Product Backlog with stakeholders | Summarize feedback, usage data, market signals, stakeholder themes | Encourage evidence-based product adaptation | Treat it as sign-off, demo-only, or AI report-out |
| Sprint Retrospective | Inspect how the Scrum Team worked and plan improvements | Cluster retro notes, identify recurring impediments, suggest experiments | Maintain psychological safety and team ownership | Use AI transcripts to blame individuals |
| Backlog refinement | Ongoing activity to clarify and split Product Backlog items | Draft acceptance criteria, identify ambiguity, suggest splits, map dependencies | Help the team make work transparent and ready enough | Assume AI-generated PBIs are validated requirements |
Scrum Artifacts and Commitments
| Artifact | Commitment | Purpose | AI support | Exam trap |
|---|---|---|---|---|
| Product Backlog | Product Goal | Ordered list of what is needed to improve the product | Draft PBIs, group related work, detect duplicates, analyze feedback | AI orders backlog without Product Owner accountability |
| Sprint Backlog | Sprint Goal | Developers’ plan for the Sprint | Suggest task breakdowns, risks, test ideas, dependencies | AI assigns tasks or fixes the plan as unchangeable |
| Increment | Definition of Done | Usable product step toward the Product Goal | Generate code, tests, documentation, review checklists | Accepting AI-created output that is not Done |
AI Essentials for a Scrum Master
| Term | Practical meaning | PSM-AI relevance |
|---|---|---|
| Artificial intelligence | Systems that perform tasks associated with human intelligence | Useful for assistance, pattern detection, generation, and automation |
| Generative AI | AI that creates text, images, code, plans, summaries, or other content | Commonly used for drafts, facilitation support, product analysis |
| Large language model | Model trained to generate and transform language-like outputs | Can produce fluent but incorrect Scrum or product advice |
| Prompt | Input or instruction given to an AI system | Prompt quality affects usefulness, but validation remains essential |
| Context | Information provided to guide the model | Poor context creates generic or misleading output |
| Hallucination | Plausible but false or unsupported output | Major risk in exam scenarios involving policy, product facts, or Scrum rules |
| Bias | Skewed or unfair output caused by data, design, or usage | Relevant to team analytics, stakeholder analysis, hiring, prioritization, and feedback |
| Prompt injection | Malicious or unintended instruction that manipulates AI behavior | Risk when using external documents, tickets, chat logs, or web content |
| Retrieval-augmented generation | AI answers using retrieved reference material | Can improve grounding but still requires verification |
| Automation | System performs a repeated task with limited human involvement | Helpful for summaries, test runs, alerts; unsafe for accountability decisions |
| Agentic AI | AI that can take steps or use tools toward a goal | Requires boundaries, permissions, monitoring, and human decision points |
| Human in the loop | Human reviews or approves AI output before use | Strong fit for Scrum decisions, quality, and risk control |
Prompting Patterns for Scrum Work
Useful Prompt Structure
| Prompt element | What to include | Why it matters |
|---|---|---|
| Role/context | Product, Sprint Goal, team context, constraints | Reduces generic advice |
| Task | Specific output requested | Keeps the model focused |
| Inputs | PBIs, feedback, policies, metrics, meeting notes | Grounds the response |
| Constraints | Scrum rules, DoD, security limits, tone, length | Prevents unsuitable suggestions |
| Output format | Table, checklist, options, risks, questions | Improves inspection |
| Validation request | Ask for assumptions, unknowns, and verification steps | Supports empiricism |
Example safe prompt pattern:
Context: We are a Scrum Team preparing Sprint Planning.
Do not make decisions for the team. Use the information below only as input.
Task: Identify ambiguities, dependencies, risks, and questions the Scrum Team
should inspect before forecasting work.
Constraints: Respect Scrum accountabilities. The Product Owner remains
accountable for ordering. Developers forecast the work. The output must not
include confidential data beyond what is provided.
Output: Table with item, concern, suggested question, and who should inspect it.
Prompting Do / Avoid
| Do | Avoid |
|---|---|
| Ask AI to generate options, questions, risks, and drafts | Ask AI to decide Sprint Goal, order backlog, or assign work |
| Request assumptions and uncertainty | Accept confident answers without evidence |
| Provide only necessary and authorized context | Paste confidential, personal, proprietary, or regulated data without approval |
| Ask for Scrum-consistent facilitation ideas | Ask for command-and-control enforcement scripts |
| Use AI output as input to inspection | Treat AI output as final product truth |
Event-by-Event AI Use Matrix
| Scrum activity | High-value AI use | Human validation needed | Strong answer in exam scenarios |
|---|---|---|---|
| Product Backlog refinement | Split large PBIs, identify missing acceptance criteria, detect duplicates | Product Owner and Developers inspect value, feasibility, clarity | Use AI as a drafting aid; PO remains accountable for Product Backlog |
| Sprint Planning | Compare options against Product Goal, surface risks, draft Sprint Goal alternatives | Scrum Team chooses Sprint Goal; Developers forecast | Facilitate conversation; do not let AI commit the team |
| Daily Scrum | Summarize changes since yesterday, highlight possible blockers | Developers inspect and adapt their plan | Keep it for Developers, not management reporting |
| Development work | Generate tests, code suggestions, documentation, examples | Developers review, integrate, test, and ensure Done | AI-created work must meet DoD |
| Sprint Review | Summarize stakeholder feedback and usage signals | Scrum Team and stakeholders inspect Increment and adapt Product Backlog | Use evidence; avoid sign-off framing |
| Retrospective | Cluster themes, draft improvement experiments | Scrum Team selects improvement actions | Preserve safety and team ownership |
| Impediment management | Detect recurring blockers, draft escalation notes | Scrum Master evaluates and acts appropriately | Remove impediments or coach team/system to resolve them |
| Stakeholder communication | Draft summaries, FAQs, release notes | Product Owner/Scrum Team verify accuracy | Communicate transparently with uncertainty where needed |
“What Should the Scrum Master Do Next?” Decision Table
| Scenario | Best next action | Why | Avoid |
|---|---|---|---|
| AI predicts the team can deliver twice its usual work next Sprint | Facilitate inspection of evidence, risks, and assumptions; Developers forecast | Forecasting is empirical and owned by Developers | Treat prediction as commitment |
| Manager wants AI to score individual Developers from tool activity | Coach against misuse; focus on team outcomes, transparency, and Scrum values | Scrum Teams self-manage; individual surveillance harms openness and respect | Ranking people by commits, story points, or meeting talk time |
| Product Owner asks AI to order the Product Backlog automatically | Help PO use AI as input while retaining accountability | PO is accountable for Product Backlog ordering | Delegating value decisions to AI |
| AI-generated acceptance criteria conflict with stakeholder need | Bring conflict to PO, Developers, and stakeholders for clarification | AI output is not validated product knowledge | Implementing generated criteria without inspection |
| Developers use AI-generated code | Ensure review, testing, integration, security checks, and DoD compliance | Done is still required | Lowering quality because AI wrote it |
| Daily Scrum becomes an AI-generated report to leadership | Coach Developers and organization on purpose of Daily Scrum | Daily Scrum is for Developers to inspect and adapt | Turning it into status reporting |
| Retro AI summary identifies a person as the “root cause” | Reframe toward system conditions, behaviors, and improvement experiments | Retrospective requires safety and respect | Blame, surveillance, or punitive action |
| AI suggests canceling the Sprint | Discuss with Product Owner; only PO has authority to cancel if Sprint Goal becomes obsolete | Scrum has specific accountability for Sprint cancellation | AI or Scrum Master cancels the Sprint |
| AI finds a likely security defect near Sprint end | Make it transparent; Developers inspect impact on Done and Increment usability | Quality and transparency matter more than hiding bad news | Shipping not-Done work silently |
| Stakeholder asks for hidden prompt logs to audit decisions | Share appropriate decision rationale and evidence within policy | Transparency matters, but confidentiality and policy still apply | Exposing sensitive data or hiding decision basis |
AI Risk and Control Checklist
| Risk | Why it matters in Scrum | Practical control |
|---|---|---|
| Confidentiality leakage | Scrum artifacts may include customer, product, security, or business-sensitive data | Use approved tools, minimize data, anonymize where appropriate |
| Hallucinated facts | False output can distort Product Backlog, planning, or stakeholder communication | Verify against trusted sources and real product evidence |
| Hidden assumptions | AI may infer priorities, effort, or dependencies incorrectly | Require assumptions and unknowns in output |
| Bias in analysis | Stakeholder feedback or team analytics can be skewed | Inspect data sources, sampling, and impact |
| Over-automation | Reduces collaboration and weakens empiricism | Keep human decision points for goals, priorities, quality, and adaptation |
| Reduced transparency | AI-generated work may hide how conclusions were reached | Label AI use and make inputs/limits visible |
| Quality degradation | Generated code/tests/docs can be incomplete or unsafe | Apply Definition of Done, reviews, testing, and engineering standards |
| Prompt injection | External content may manipulate model behavior | Treat untrusted content carefully; isolate instructions from data |
| Dependency on tools | Team may lose skill or judgment | Use AI to augment learning, not replace competence |
| Misuse of metrics | AI can amplify misleading productivity measures | Prefer outcome, flow, quality, and learning signals over individual output metrics |
AI Working Agreement Topics for Scrum Teams
| Topic | Working agreement question |
|---|---|
| Allowed tools | Which AI tools are approved for product, code, meeting, and documentation work? |
| Data boundaries | What information must never be entered into AI tools? |
| Disclosure | When do we label content as AI-assisted? |
| Review | What AI-generated outputs require peer review, PO review, or security review? |
| Definition of Done | How does AI-assisted work prove it is Done? |
| Prompt storage | Should prompts and outputs be retained for traceability? |
| Retrospective safety | Are AI transcripts or summaries allowed? Who can access them? |
| Stakeholder communication | Who validates AI-generated release notes, summaries, or forecasts? |
| Tool failure | What is our fallback when AI output is unavailable, low quality, or unsafe? |
| Continuous improvement | How will we inspect AI use in Retrospectives? |
Scrum Master Stances With AI
| Stance | AI-supported behavior | Poor substitute behavior |
|---|---|---|
| Teacher | Use AI to generate examples, quizzes, and explanations of Scrum concepts | Let AI teach incorrect Scrum without review |
| Coach | Generate coaching questions and reflection prompts | Use AI to tell people what to do |
| Facilitator | Prepare structures for planning, review, refinement, and retrospectives | Replace conversation with AI summaries |
| Impediment remover | Analyze recurring blockers and draft escalation options | Wait for AI to solve organizational issues |
| Change agent | Use data to expose systemic constraints | Use dashboards to pressure teams |
| Servant-leader / true leader | Help people improve transparency, inspection, adaptation, and self-management | Become a controller of AI tools and metrics |
Scrum-Specific Distinctions Likely to Be Tested
| Distinction | Correct framing |
|---|---|
| AI recommendation vs empirical evidence | AI output is an input for inspection, not a substitute for evidence |
| Forecast vs commitment | Developers forecast work; Sprint Goal provides commitment and focus |
| Productivity vs value | More generated output is not necessarily more product value |
| Velocity vs performance target | Velocity may help forecasting but should not be used to pressure teams |
| Done vs “almost done” | AI-generated work is not usable unless it meets the Definition of Done |
| Automation vs accountability | Automation can execute tasks; people remain accountable |
| Transparency vs surveillance | Transparency supports inspection; surveillance harms trust and self-management |
| Facilitation vs decision-making | Scrum Master facilitates; Product Owner and Developers retain their accountabilities |
| Sprint Review vs approval gate | Sprint Review inspects Increment and adapts Product Backlog; it is not merely sign-off |
| Retrospective analysis vs blame | Retro data should support improvement, not individual fault-finding |
Common Exam Traps
| Trap answer | Better answer |
|---|---|
| “Use AI to assign tasks to Developers.” | Developers self-manage and decide how to do the work. |
| “Let AI select the Sprint Goal from the top backlog items.” | Scrum Team crafts the Sprint Goal during Sprint Planning. |
| “AI-generated acceptance criteria are ready for development.” | Product Owner and Developers inspect and refine them. |
| “AI says the Increment is shippable.” | The Increment is usable only if it satisfies the Definition of Done. |
| “The Scrum Master should use AI to monitor individual performance.” | The Scrum Master should coach toward team outcomes, trust, and empirical improvement. |
| “AI can replace stakeholder collaboration.” | AI may summarize feedback; stakeholders and Scrum Team still inspect and adapt together. |
| “AI-generated forecasts should drive management commitments.” | Forecasts are uncertain and must be empirically inspected. |
| “The AI tool is the source of truth.” | Scrum artifacts, evidence, and transparent inspection are the source of truth. |
| “If AI improves efficiency, Scrum events can be skipped.” | Scrum events are formal opportunities for inspection and adaptation. |
| “AI can lower documentation or test effort.” | Quality standards and Done remain unchanged. |
Fast Review Checklist
Before the exam, confirm you can answer these quickly:
- Who is accountable for Product Backlog ordering? Product Owner.
- Who forecasts Sprint work? Developers.
- Who is accountable for Scrum effectiveness? Scrum Master.
- Can AI own a Scrum accountability? No.
- Can AI help generate PBIs, acceptance criteria, tests, summaries, and risks? Yes, as assistive input.
- What must happen to AI output before use? Human inspection and validation.
- What protects quality? Definition of Done plus team engineering standards.
- What protects empirical process control? Transparency, inspection, and adaptation.
- What should the Scrum Master do when AI use reduces collaboration? Coach and facilitate better Scrum use.
- What should the Scrum Team inspect in Retrospectives about AI? Value, risk, quality, transparency, and team impact.
Practical Next Step
Use this Quick Reference to review the Scrum accountabilities, artifacts, events, and AI decision points, then practice with scenario-based PSM-AI questions that force you to choose the best Scrum Master action rather than the most technically impressive AI option.