Patterns

Scenario: team is dependent on a manager for task assignments

Best answer:

• Scrum Master coaches Developers and organization on self-management.
• Developers decide how to turn Product Backlog items into Done Increment.

Wrong answer:

• Scrum Master becomes the new task manager.

Scenario: organization says Scrum is failing because old governance is not followed

Best answer:

• Scrum Master helps the organization understand Scrum and empiricism.
• Inspect whether the governance step is useful or wasteful.
• Keep necessary compliance but integrate it transparently into Done and Product Backlog.

Wrong answer:

• Remove all governance because “Scrum has no rules.”

Scenario: conflict between Developers and Product Owner

Best answer:

• Scrum Master facilitates conversation and improves understanding of accountabilities.
• The Product Owner remains accountable for Product Backlog ordering.
• Developers remain accountable for Sprint Backlog and quality.

Wrong answer:

• Scrum Master decides product priority or technical assignments.

Traps

• “Servant leader” does not mean administrative assistant.
• “Remove impediments” does not mean doing everyone’s work.
• “Coaching” does not mean forcing Scrum mechanically.
• “Self-management” does not mean no accountability.
• “Facilitation” does not mean taking over decisions.

Domain 3: Managing Products with Agility

Concepts

This domain focuses on maximizing value through Product Ownership and empirical product management.

Product Owner accountability

The Product Owner is accountable for maximizing value. This includes:

• Developing and communicating the Product Goal.
• Creating and clearly communicating Product Backlog items.
• Ordering Product Backlog items.
• Ensuring the Product Backlog is transparent, visible, and understood.

The Product Owner may delegate work, but remains accountable.

Product Goal

The Product Goal is the commitment for the Product Backlog. It provides a long-term objective for the Scrum Team.

Exam rules:

• Product Backlog items should align with the Product Goal.
• The Scrum Team fulfills or abandons one Product Goal before taking on the next.
• The Product Goal gives direction; it is not a fixed scope contract.

Product Backlog management

The Product Backlog is:

• Ordered.
• Emergent.
• Transparent.
• The single source of work undertaken by the Scrum Team.

Ordering can consider value, risk, dependencies, learning, cost, and stakeholder needs.

Stakeholders and customers

Stakeholders should collaborate regularly with the Scrum Team, especially at Sprint Review. They provide feedback that helps adapt the Product Backlog.

They do not:

• Assign tasks to Developers.
• Override Product Owner accountability.
• Approve Done as a substitute for Definition of Done.
• Change the Sprint Goal directly.

Forecasting and release planning

Scrum allows forecasting, but forecasts are empirical. The best answer uses evidence such as:

• Past delivery data.
• Current Product Backlog ordering.
• Product Goal progress.
• Inspection at Sprint Review.

Avoid answers that promise fixed scope, fixed date, and fixed cost without empirical uncertainty.

Patterns

Scenario: stakeholder requests a feature urgently

Best answer:

• Product Owner discusses value and ordering.
• Item may be added to the Product Backlog.
• It does not automatically interrupt the Sprint.

Scenario: many stakeholders disagree on priority

Best answer:

• Product Owner makes ordering decisions to maximize value.
• Scrum Master may facilitate stakeholder collaboration.
• Evidence from Sprint Review helps inspect and adapt.

Scenario: management wants a detailed annual plan

Best answer:

• Provide transparent empirical forecasts and communicate uncertainty.
• Use Product Goal and Product Backlog ordering.
• Do not pretend complex work is fully predictable.

Traps

• Product Owner is not a committee.
• Stakeholders influence, but Product Owner orders the Product Backlog.
• Product Backlog is not a fixed requirements document.
• Sprint Review is not a sign-off meeting.
• Forecasts are not commitments.

5. Service Selection Guide

PSM I is not a cloud/vendor service-selection exam. Instead, it tests Scrum decision selection: choosing the correct accountability, event, artifact, or empirical response.

Accountability selection table

Event selection table

Artifact and commitment selection table

When not to choose common wrong answers

6. Architecture Patterns

In PSM I, “architecture patterns” means Scrum operating patterns: how the framework should be applied in realistic organizational contexts.

Pattern 1: Empirical product delivery

Scenario: The organization wants certainty in a complex product.

Recommended solution:

• Use short Sprints.
• Create Done Increments.
• Inspect with stakeholders at Sprint Review.
• Adapt Product Backlog based on evidence.

Why alternatives are wrong:

• Big upfront plans assume predictability that may not exist.
• Delayed integration hides risk.
• Approval gates reduce transparency if they replace inspection.

Pattern 2: One product, multiple teams

Scenario: Several Scrum Teams work on the same product.

Recommended solution:

• One Product Backlog.
• One Product Goal.
• Integrated Increment each Sprint.
• Shared Definition of Done.

Why alternatives are wrong:

• Separate Product Backlogs can fragment value.
• Separate Definitions of Done can create integration and quality gaps.
• Component teams can create handoffs unless carefully managed.

Pattern 3: Compliance-heavy environment

Scenario: A regulated product requires audit, security, or compliance.

Recommended solution:

• Make compliance work transparent in Product Backlog and Definition of Done.
• Build compliance into each Increment.
• Inspect compliance evidence regularly.

Why alternatives are wrong:

• A final compliance Sprint creates hidden risk.
• Ignoring compliance is not professional Scrum.
• Turning every Sprint Review into a bureaucratic approval board weakens empiricism.

Pattern 4: Stakeholder conflict

Scenario: Stakeholders disagree about priorities.

Recommended solution:

• Product Owner orders Product Backlog to maximize value.
• Scrum Master may facilitate collaboration.
• Sprint Review provides transparency and feedback.

Why alternatives are wrong:

• Stakeholder voting does not replace Product Owner accountability.
• Scrum Master should not become product decision maker.
• Developers should not be forced to satisfy conflicting stakeholder demands directly.

Pattern 5: Low quality and repeated carryover

Scenario: Many items are unfinished or defects appear after Sprint.

Recommended solution:

• Strengthen Definition of Done.
• Improve engineering practices.
• Use Sprint Retrospective to inspect causes.
• Keep undone work out of the Increment.

Why alternatives are wrong:

• Extending Sprints hides forecasting problems.
• Carrying partially Done work as Done destroys transparency.
• Creating a separate test team can increase handoffs unless the Scrum Team remains accountable for Done.

7. Exam Traps

Misleading wording

Watch for words like:

• Must — is this actually required by Scrum?
• Always — Scrum rarely says always outside framework rules.
• Best — choose the answer most consistent with Scrum values and empiricism.
• Approve — often a trap around Sprint Review.
• Assign — often a trap around self-management.
• Commit to scope — often a trap; Sprint Goal is the commitment, not every item.
• Report to Scrum Master — often a Daily Scrum trap.

Wrong-but-plausible answers

Common distractors

• Add a new role not in Scrum.
• Use a project manager to coordinate Developers.
• Make Scrum Master enforce estimates or velocity.
• Ask stakeholders to directly order the Product Backlog.
• Delay testing to later.
• Protect the team by hiding stakeholder feedback.
• Choose process compliance over empirical learning.

Elimination strategy

Use this four-step filter:

1. Scrum legality: Is the answer allowed by Scrum?
2. Accountability: Is the right accountability making the decision?
3. Empiricism: Does it improve transparency, inspection, and adaptation?
4. Value and Done: Does it help create a valuable Done Increment?

If an option adds control, secrecy, approval bureaucracy, late quality, or external task assignment, it is probably wrong.

8. Quick Memory Rules

Rules of thumb

• Product Owner owns value and Product Backlog ordering.
• Developers own Sprint Backlog, quality, and how to build.
• Scrum Master owns Scrum effectiveness through coaching and service.
• Sprint Goal is the commitment for the Sprint Backlog.
• Product Goal is the commitment for the Product Backlog.
• Definition of Done is the commitment for the Increment.
• Daily Scrum is for Developers, not a report to management.
• Sprint Review is about product inspection and adaptation.
• Sprint Retrospective is about team process improvement.
• Undone work is not part of the Increment.
• Sprint is fixed; do not extend it.
• Forecasts are empirical; they are not guarantees.

Fast mapping

“If you see X, think Y” patterns

• If you see approval board, think: Sprint Review is not a gate.
• If you see status report, think: Daily Scrum is for Developers to adapt plan.
• If you see manager assigns, think: self-management violation.
• If you see done later, think: not Done now.
• If you see scope commitment, think: Sprint Goal commitment.
• If you see urgent stakeholder request, think: Product Owner evaluates value and ordering.
• If you see uncertain release date, think: empirical forecast.
• If you see low trust, think: transparency and frequent inspection.
• If you see compliance, think: integrate into Definition of Done and Product Backlog.

9. Final Revision Notes

Highest-yield review points

1. Scrum Team has no hierarchy and no sub-teams.
2. Developers are accountable for creating a Done Increment each Sprint.
3. Product Owner is accountable for Product Backlog and value.
4. Scrum Master coaches the team and organization; does not command the team.
5. Sprint Review is not a demo-only meeting and not an approval gate.
6. Daily Scrum is not required to use the three classic questions.
7. Sprint Retrospective should produce actionable improvement.
8. Definition of Done determines whether work can be part of the Increment.
9. The Sprint Goal gives focus and flexibility.
10. Only the Product Owner can cancel a Sprint when the Sprint Goal becomes obsolete.
11. Product Backlog is emergent and ordered, not frozen.
12. Multiple teams on one product need integrated work and coherent quality.
13. Do not add roles like project manager, test manager, business analyst as Scrum accountabilities.
14. Scrum does not forbid governance, but governance must not destroy empiricism.
15. Empirical decisions beat detailed speculative plans in complex work.

Last-day revision list

Review these until instant:

• Scrum values: commitment, focus, openness, respect, courage.
• Pillars: transparency, inspection, adaptation.
• Accountabilities: Product Owner, Scrum Master, Developers.
• Events and time-boxes.
• Artifacts and commitments.
• Done vs undone work.
• Sprint Goal vs Sprint Backlog items.
• Product Goal vs Product Backlog.
• Stakeholder role in Sprint Review.
• Scrum Master service to organization.

Mini decision framework

When stuck between two answers:

• Prefer coaching over commanding.
• Prefer transparency over hiding.
• Prefer inspection/adaptation over fixed prediction.
• Prefer Done Increment over partial progress.
• Prefer right accountability over committee decision.
• Prefer Scrum Guide language over generic agile jargon.

10. Exam-Day Checklist

Must-know topics

• Scrum theory: empiricism and lean thinking.
• Scrum pillars: transparency, inspection, adaptation.
• Scrum values and how they affect behavior.
• Product Owner accountability.
• Scrum Master accountability.
• Developers accountability.
• Sprint purpose and rules.
• Sprint Planning: why, what, how.
• Daily Scrum purpose.
• Sprint Review purpose.
• Sprint Retrospective purpose.
• Product Backlog and Product Goal.
• Sprint Backlog and Sprint Goal.
• Increment and Definition of Done.
• What happens to undone work.
• Who can cancel a Sprint.
• How Product Backlog ordering works.
• How stakeholders give feedback.
• How Scrum handles compliance.
• How multiple teams work on one product.

Final confidence checklist

Before exam day, you should be able to answer these without hesitation:

• Who orders the Product Backlog?
• Who owns the Sprint Backlog?
• Who creates the Increment?
• What is the purpose of the Sprint Goal?
• What makes work part of the Increment?
• What is the purpose of the Sprint Review?
• What is the purpose of the Sprint Retrospective?
• What should happen when work is not Done?
• What should happen when stakeholders request urgent changes?
• What should the Scrum Master do when the organization resists Scrum?

Final warning

PSM I questions are often short but precise. Read every word. The wrong answer is often only wrong because of one phrase such as assign, approve, guarantee, extend, report, must, or later.

If an answer weakens empiricism, hides reality, delays quality, adds a non-Scrum authority, or violates accountabilities, eliminate it.

Ultra-Rapid One-Page Review