PSM cheat sheet
PSM · Keep the key ideas within reach.
Understanding and Applying the Scrum Framework: Empiricism, Scrum Values
Empiricism: knowledge comes from experience; make decisions based on what is observed, not on assumptions or predictions.
Three empirical pillars: transparency (work and state visible), inspection (frequent checks of artifacts and progress), adaptation (adjust based on inspection).
Transparency enables inspection; inspection without transparency is misleading and wasteful.
Scrum Values: Commitment, Focus, Openness, Respect, Courage. They guide behavior and reduce risk of decisions being undermined.
Commitment: team commits to achieving goals; Focus: primary focus on Sprint work; Openness: transparent about work and challenges.
Respect: team members respect each other as capable independent people; Courage: do the right thing and tackle tough problems.
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Scrum Team
Scrum Team consists of one Scrum Master, one Product Owner, and Developers; no sub-teams or hierarchies; size typically 10 or fewer.
Product Owner: accountable for maximizing product value, managing Product Backlog, and communicating product goal.
Scrum Master: accountable for establishing Scrum as defined in the Scrum Guide; serves the Scrum Team and organization.
Developers: accountable for creating a usable Increment each Sprint, adapting plan daily, and holding each other accountable.
Scrum Team is cross-functional: has all skills necessary to create value each Sprint.
Scrum Team is self-managing: internally decides who does what, when, and how.
Product Owner may delegate work but remains accountable; cannot delegate accountability.
Scrum Master is a true leader who serves the Scrum Team, not a project manager or people manager.
Scrum Events
Five events: Sprint (container), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Sprint: fixed length of one month or less; new Sprint starts immediately after previous; no changes to Sprint Goal.
Sprint Planning: timeboxed to max 8 hours for one-month Sprint; covers Why (Sprint Goal), What (Backlog items), How (plan).
Daily Scrum: 15-minute event for Developers; inspect progress toward Sprint Goal and adapt Sprint Backlog; same time and place.
Sprint Review: max 4 hours for one-month Sprint; inspect outcome, determine future adaptations, update Product Backlog.
Sprint Retrospective: max 3 hours for one-month Sprint; inspect individuals, interactions, processes, tools, Definition of Done.
Events are formal opportunities to inspect and adapt; they create regularity and minimize need for other meetings.
Timeboxes are maximum durations; shorter Sprints proportionally reduce timebox (e.g., 2-week Sprint: Planning 4h, Review 2h, Retro 1.5h).
Scrum Artifacts
Three artifacts: Product Backlog, Sprint Backlog, Increment. Each has a commitment: Product Goal, Sprint Goal, Definition of Done.
Product Backlog: emergent, ordered list of what is needed to improve the product; single source of work for Scrum Team.
Sprint Backlog: composed of Sprint Goal (why), selected Product Backlog items (what), and plan for delivering (how).
Increment: concrete stepping stone toward Product Goal; must be usable to provide value; multiple Increments may exist in a Sprint.
Definition of Done: formal description of state of Increment when it meets quality measures required for product.
Product Goal: long-term objective for Scrum Team; describes future state of product; one at a time.
Sprint Goal: single objective for Sprint; provides focus and flexibility; created during Sprint Planning.
Artifacts are inspected and adapted during events; commitments reinforce empiricism.
Definition of Done
Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product.
If DoD is an organizational standard, all Scrum Teams must follow it as a minimum; if not, team creates its own.
Developers are accountable for creating a DoD; it is used to assess when work on a Product Backlog item is complete.
Work that does not meet DoD cannot be released or presented at Sprint Review; it returns to Product Backlog.
DoD is created during Sprint Planning if not already defined; it evolves over time.
A stronger DoD improves transparency and quality; a weaker DoD can hide incomplete work.
DoD is inspected during Sprint Retrospective for potential improvements.
Increment is delivered when it meets DoD; multiple Increments can be created within a Sprint.
Developing People and Teams: Self-Managing Teams
Self-managing teams internally decide who does what, when, and how; they are not directed by others outside the team.
Self-managing does not mean no boundaries: the team operates within organizational constraints and Scrum rules.
Self-managing teams require trust, psychological safety, and clear goals to function effectively.
Scrum Master supports self-management by coaching, facilitating, and removing impediments, not by assigning tasks.
Cross-functionality and self-management together enable the team to deliver value each Sprint.
Managers shift from directing work to creating an environment where self-managing teams can thrive.
Self-managing teams hold each other accountable for quality and outcomes.
Empowerment is not abdication: accountability remains with the team for its commitments.
Facilitation
Facilitation is about designing and guiding group processes to achieve a clear purpose, not about content expertise.
A facilitator remains neutral on content, focuses on process, and ensures all voices are heard.
Effective facilitation uses techniques like round-robin, dot voting, fist of five, and silent writing to avoid groupthink.
Scrum Master facilitates Scrum events as requested or needed, ensuring they are positive, productive, and timeboxed.
Facilitation includes setting ground rules, managing participation, and handling conflict constructively.
Visual facilitation (flip charts, sticky notes, digital boards) increases transparency and engagement.
Facilitator should clarify purpose and desired outcome before selecting techniques.
After events, facilitation includes capturing decisions and action items for transparency.
Coaching
Coaching is a collaborative, reflective process that helps individuals and teams unlock their potential.
Coaching focuses on asking powerful questions rather than giving advice or solutions.
Key coaching skills: active listening, open questions, paraphrasing, summarizing, and providing feedback.
Scrum Master coaches the Scrum Team and organization in Scrum adoption and empirical practices.
Coaching supports self-management by helping teams find their own answers.
Coaching distinguishes between mentoring (sharing experience) and teaching (imparting knowledge).
Coaching agreements clarify goals, confidentiality, and boundaries.
Effective coaching requires trust, presence, and curiosity.
Managing Products with Agility: Forecasting & Release Planning
Forecasting is probabilistic; use historical data (velocity, cycle time) to predict future delivery, not to guarantee.
Velocity is a trailing indicator: average of past Sprint results; use range rather than single number.
Release planning is emergent; plan based on empirical data and adjust as more is learned.
Use burn-up charts to show scope and progress toward a release goal.
Little's Law: average cycle time = work in process (WIP) / throughput; reducing WIP improves cycle time.
Cone of Uncertainty: estimates are more uncertain early; reforecast as knowledge increases.
Monte Carlo simulation can forecast completion dates using historical cycle times.
Release planning should consider Product Goal, stakeholder needs, and technical dependencies.
Product Value
Product value is the measure of outcomes that benefit customers and the organization; it is not just output.
Product Owner maximizes value by ordering the Product Backlog and making trade-off decisions.
Value can be assessed through customer feedback, usage metrics, revenue, and stakeholder input.
The Increment must be usable to provide value; value is realized when customers use it.
Value is emergent and context-specific; what is valuable may change over time.
Product Goal provides a long-term objective that guides value delivery.
Avoid measuring value solely by velocity or story points; focus on outcomes.
Scrum Team should regularly inspect value delivered and adapt.
Product Backlog Management
Product Backlog is an emergent, ordered list of what is needed to improve the product; it is the single source of work.
Product Owner is accountable for effective Product Backlog management, including ordering and clarity.
Backlog refinement is the act of breaking down and further defining Product Backlog items; it is ongoing.
Ordering should maximize value; items at top are clearer and more detailed for upcoming Sprint.
Product Backlog items can be features, bug fixes, non-functional requirements, and experiments.
The Product Backlog is never complete; it evolves as the product and environment change.
Stakeholders can provide input, but the Product Owner decides ordering.
Product Goal is the commitment for the Product Backlog; it provides direction.
Stakeholders & Customers
Stakeholders are people with interest in the product; customers are those who receive value.
Product Owner engages stakeholders to understand needs and priorities.
Sprint Review is a key event to collaborate with stakeholders and inspect the Increment.
Stakeholder feedback informs Product Backlog ordering and adaptation.
Customers provide feedback through usage and direct interaction; their input is essential for value.
Managing stakeholder expectations includes transparency about progress and forecasts.
Scrum Master may facilitate collaboration between Scrum Team and stakeholders.
Stakeholder engagement is continuous, not only at Sprint Review.