Here are 100 high-quality, learning-oriented PSM (Professional Scrum Master) questions and answers covering PSM I, II, III levels, designed for deep mastery, not just memorization.
Answer: Scrum is a lightweight framework for developing, delivering, and sustaining complex products through adaptive solutions using iterative and incremental approaches.
Answer: Scrum Master, Product Owner, Developers.
Answer: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Answer: Product Backlog, Sprint Backlog, Increment.
Answer: A single objective set during Sprint Planning that guides the Development Team on why the Sprint is valuable.
Answer: One month or less.
Answer: The Product Owner.
Answer: The Developers.
Answer: 15 minutes.
Answer: To inspect the Increment and adapt the Product Backlog if needed.
Answer: To inspect the past Sprint and create a plan for improvements.
Answer: The Scrum Master.
Answer: No, only the Developers can modify the Sprint Backlog.
Answer: The sum of all Product Backlog items completed during a Sprint and previous Sprints, usable and potentially releasable.
Answer: A framework.
Answer: The visibility of significant aspects of the process to those responsible for the outcome.
Answer: A process control theory that asserts knowledge comes from experience and making decisions based on what is known.
Answer: Transparency, Inspection, Adaptation.
Answer: Commitment, Courage, Focus, Openness, Respect.
Answer: Yes, only by the Product Owner, if the Sprint Goal becomes obsolete.
Answer: The Scrum Team.
Answer: A maximum of 8 hours.
Answer: The Scrum Team.
Answer: It goes back to the Product Backlog for re-prioritization.
Answer: Yes, by helping the Developers remove impediments.
Answer: They may attend but only Developers participate.
Answer: An item in the Product Backlog describing a feature, fix, or requirement.
Answer: The act of adding detail, estimates, and order to Product Backlog items.
Answer: The Product Owner.
Answer: To ensure Scrum is understood and enacted.
Answer: The Developers.
Answer: It is not recommended as it can create conflicts of interest.
Answer: No, it can be applied to any complex work.
Answer: By helping with Product Backlog management, facilitating stakeholder collaboration, and supporting Scrum understanding.
Answer: By leading and coaching Scrum adoption, planning Scrum implementations, and removing barriers between stakeholders and Scrum Teams.
Answer: A leader who focuses on the needs of the team and helps them develop and perform as highly as possible.
Answer: By empowering the team, encouraging decision-making, and removing impediments without micromanaging.
Answer: The cost of additional rework caused by choosing quick, easy solutions now instead of using a better approach.
Answer: By educating, demonstrating value, and facilitating discussions to address concerns.
Answer: By using clear, visible artifacts and information radiators.
Answer: By frequent inspection and adaptation using transparency of artifacts and events.
Answer: By encouraging ownership, clear Definition of Done, and team-driven commitments.
Answer: Yes, if they focus on mentoring and system improvements, not command-and-control.
Answer: By facilitating open dialogue and helping the team resolve conflicts themselves.
Answer: Help the organization understand the importance of the Product Owner’s role.
Answer: The Scrum Master should protect the Sprint and explain the impact of changes on commitments.
Answer: Facilitate open discussion, coaching, and encourage accountability within the team.
Answer: By team improvement, delivery rates, stakeholder satisfaction, and impediment resolution speed.
Answer: Only if they are part of the Developers; otherwise, they may attend to observe.
Answer: By teaching value-based prioritization and refinement techniques.
Answer: It’s part of learning; review in Retrospective and adjust in the next Sprint.
Answer: Identify them early, manage transparently, and work to reduce them over time.
Answer: By educating management on Scrum principles and benefits of self-organizing teams.
Answer: Useful metrics include lead time, cycle time, defect rates, and value delivery (not velocity alone).
Answer: Velocity may vary; focus should be on sustainable delivery and improvement.
Answer: Use virtual boards, video calls, and overlapping working hours to maintain collaboration.
Answer: It may encourage gaming the system and reduce quality or collaboration.
Answer: No, it remains fixed, but the Sprint Backlog may evolve to achieve it.
Answer: Inspect in Retrospective, learn, and adapt.
Answer: Help the team and stakeholders manage and minimize interruptions.
Answer: Acting as a Project Manager, controlling decisions, and shielding the team excessively.
Answer: A non-mandatory checklist indicating that Product Backlog Items are ready for Sprint Planning.
Answer: Yes, all quality activities needed for a usable Increment should be included.
Answer: Facilitate cross-skilling and knowledge sharing.
Answer: Yes, Scrum can integrate with XP, Kanban, or DevOps practices.
Answer: The Increment meets the Definition of Done and could be released if the Product Owner decides.
Answer: Advise them on the cost of cancellation, confirm the change's significance, and support the decision if necessary.
Answer: Facilitate reflection in Retrospectives and coaching on empirical forecasting based on past performance.
Answer: Model values, facilitate discussions, and encourage practices reflecting them.
Answer: Liberating structures, timeline exercises, or root cause analysis techniques.
Answer: Coach the PO on trust, the benefits of self-organization, and clarify role boundaries.
Answer: No, estimation is done by Developers.
Answer: Educate them on transparency in Scrum and offer participation in Sprint Reviews.
Answer: Discuss privately, uncover reasons, and coach on the importance of participation.
Answer: Using Nexus, LeSS, or Scrum@Scale while ensuring Scrum principles remain intact.
Answer: Possible, but effectiveness may decrease; context-dependent.
Answer: Facilitate discussions and clarify the Product Owner’s accountability for the Product Backlog.
Answer: Incrementally, focusing on mindset change, not just process mechanics.
Answer: By fostering short feedback loops, transparency, and continuous inspection and adaptation.
Answer: Coach the Product Owner on effective backlog refinement and prioritization.
Answer: Through adherence to the Definition of Done and embedding quality practices.
Answer: Explain empirical forecasting, use Product Backlog projections with clear uncertainty limitations.
Answer: Explore reasons, demonstrate value, and experiment with different formats.
Answer: Encourage open dialogue, avoid blame, and support experimentation.
Answer: By showing the benefits of Scrum, aligning Scrum with organizational goals, and providing education.
Answer: Encourage pulling in more work aligned with the Sprint Goal.
Answer: Facilitate discussion, clarify roles, and focus on customer value.
Answer: Facilitate actionable Retrospectives, collect metrics, and foster experimentation.
Answer: Facilitate discussions to address it in Sprint Planning and Product Backlog prioritization.
Answer: Discuss trade-offs with the Product Owner, consider capacity for urgent issues.
Answer: Encourage T-shaped skills, knowledge sharing, and pair programming.
Answer: By protecting the team from unnecessary disruptions and clarifying the Sprint Goal.
Answer: Educate stakeholders on sustainable pace and value over velocity.
Answer: Use metrics for team improvement, not individual performance evaluation.
Answer: Visualize dependencies and address them through refinement and planning coordination.
Answer: Leading by example, coaching, and removing systemic impediments.
Answer: Educate on the ROI of Retrospectives and their role in continuous improvement.
Answer: Clarify that Sprint length is fixed; incomplete work returns to the Product Backlog.
Answer: Facilitate better forecasting, refinement, and right-sizing of PBIs.
Answer: Enabling continuous improvement, fostering self-management, and modeling Scrum values to create a culture of empiricism.
Here are 100 of the most insightful and important Scrum Guide concepts that set Scrum apart from traditional project management, focusing on what actually makes agile different per the Scrum Guide (2020 edition) and practical application up to PSM III level:
Empiricism: Transparency, Inspection, Adaptation.
Scrum Values: Commitment, Focus, Openness, Respect, Courage.
Self-managing teams.
Cross-functional teams.
Incremental delivery.
Iterative progress.
Embrace change over following a fixed plan.
Delivering value early and continuously.
Trust and empowerment of the team.
Transparency of work, goals, and progress.
“Done” means potentially releasable.
Collaboration with stakeholders frequently.
Inspect and adapt at every Sprint.
Fail fast, learn fast.
Use empiricism to manage complexity.
No project manager role in Scrum.
Product Owner maximizes product value.
Developers manage their own work.
Scrum Master serves the Scrum Team.
Whole-team accountability for results.
Product Owner: single person accountable for Product Backlog.
Scrum Master: accountable for Scrum effectiveness.
Developers: accountable for creating the Increment.
No project manager to assign tasks.
The Scrum Master removes impediments but does not manage the team.
Product Owner collaborates with stakeholders, not commands the team.
Developers decide how to accomplish the work.
No “boss-subordinate” relationship within the Scrum Team.
Scrum Team is small (10 or fewer).
Scrum Team includes PO, SM, and Developers only, no others.
Product Backlog: single source of work for the product.
Sprint Backlog: selected Product Backlog Items + plan for delivery.
Increment: the sum of all completed work in the Sprint.
Product Goal: commitment for the Product Backlog.
Sprint Goal: commitment for the Sprint Backlog.
Definition of Done: commitment for the Increment.
Product Backlog is emergent and refined continuously.
Sprint Backlog is owned by Developers.
Increment must meet Definition of Done to be considered complete.
No “requirements specification” separate from Product Backlog.
Sprint: fixed-length event (max 1 month).
Sprint Planning: creates Sprint Goal and initial Sprint Backlog.
Daily Scrum: 15-min inspection and adaptation event.
Sprint Review: inspect Increment and adapt Product Backlog.
Sprint Retrospective: inspect and adapt team processes.
Sprint starts immediately after the previous one ends.
No gaps between Sprints.
All work happens within the Sprint.
Canceling a Sprint is rare and only done by Product Owner.
Timeboxing ensures focus and reduces waste.
What can be delivered in the Sprint?
How will the work be achieved?
Why is the Sprint valuable? (Sprint Goal)
Developers forecast what they can accomplish.
PO ensures Product Backlog is ready for planning.
SM facilitates but does not decide.
Held at the same time, same place.
Developers only, but SM/PO can attend as listeners.
Not a status meeting for the SM/PO.
Focuses on progress toward Sprint Goal.
Adapt the plan for the next 24 hours.
Encourages self-organization.
Developers update Sprint Backlog as needed.
Held at the end of the Sprint.
Collaborative working session with stakeholders.
Demonstrate the Increment.
Discuss what to do next based on feedback.
Adapt Product Backlog if needed.
Not just a demo, but an inspection and adaptation event.
Focuses on team process improvements.
Last event in the Sprint.
Can result in actionable improvements for the next Sprint.
Team inspects people, process, tools, relationships.
Builds continuous improvement habit.
Refinement is ongoing, not an event in the Guide.
PO collaborates with Developers.
Breaks down and defines clearer PBIs.
Estimates may be added.
Ensures upcoming items are ready for planning.
No Gantt charts or critical path planning.
Scope is flexible; time and cost are fixed.
Forecasting, not detailed up-front planning.
Work is pulled, not pushed.
Team commitment to Sprint Goal, not tasks.
Stakeholders see progress frequently, not at the end.
Predictability through empiricism, not rigid plans.
Progress measured via working increments, not % complete.
Managing risks by delivering early and often.
PO manages product value, not tasks.
No command-and-control hierarchy.
Planning happens at multiple levels, frequently.
Focus on delivering value, not completing tasks.
Emphasis on team health and sustainability.
Encourages learning and adaptability.
No role for “project manager” assigning or controlling.
Decisions made based on current information, not assumptions.
Product Goal provides long-term direction.
Sprint Goal provides short-term focus.
Definition of Done ensures quality is maintained consistently.
Scrum is a lightweight framework, not a methodology with heavy processes.
These 100 key concepts will set you apart from a traditional project manager, allowing you to:
✅ Lead with agile values and empirical process control.
✅ Embrace self-management, frequent delivery, and adaptability.
✅ Facilitate value delivery and stakeholder collaboration instead of controlling tasks.
✅ Use Scrum Guide structure to anchor your practices without drifting into waterfall-in-Scrum.