Scrum Framework: PSM1 Study Guide

The Scrum philosophy is empirical and lean; it’s realized through the three pillars of transparency, inspection, and adaptation, and sustained by the five values of commitment, courage, focus, openness, and respect. Its purpose is to continuously add value.

Scrum provides a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

It is not a process or technique; instead, it outlines how to think and collaborate empirically. Scrum makes visible the relative efficacy of current management, environment, and work techniques so that improvements can be made.

Scrum stands on three pillars that uphold empirical process control:

• Transparency: Work and progress must be visible and understood by all stakeholders.
• Inspection: Scrum artifacts and progress toward agreed goals are inspected frequently.
• Adaptation: When deviation or drift is detected, the team adjusts its processes or materials as soon as possible.

Scrum teams embody five core values:

• Commitment: The team is dedicated to achieving its goals and supporting one another.
• Courage: Members have the courage to do the right thing and address tough challenges.
• Focus: Everyone concentrates on the work of the Sprint and the goals of the team.
• Openness: The team and stakeholders are open about work and challenges.
• Respect: Individuals respect each other as capable, independent people.

Members: Product Owner, Scrum Master, and Developers working as a single, self-managing unit.
Suggested Size: Around 10 or fewer people — small enough to remain nimble and large enough to deliver meaningful work within a Sprint.
Important: There is no Project Manager role in Scrum. Responsibilities for planning, tracking, and improvement are shared among the team.

Main Function: Deliver valuable, usable Increments each Sprint through collaboration, transparency, and continuous improvement.

Key Notes:

• Cross-functional: Each Scrum Team contains all the skills needed to deliver a Done Increment without depending on others.
• Self-managing: The team decides internally who does what, when, and how.
• Self-forming: When multiple Scrum Teams are needed (e.g., 30 people dividing into three teams), they should form themselves based on skills and collaboration patterns. Each team must be capable of delivering a complete Increment independently.
• Member changes: Developers may be switched out when necessary; it is expected that velocity may temporarily decrease while new team members integrate and build shared understanding.
• Accountability: The Scrum Team as a whole is accountable for product value, quality, and delivery each Sprint.

Product Owner
Core Responsibility: Maximize product value by managing the Product Backlog and clearly expressing the Product Goal, priorities, and order.

Note: No matter how many Scrum Teams are working on the same product, there is exactly one Product Owner and one Product Backlog for that product. This ensures a single, unified direction and avoids conflicting priorities or duplicated work.
Developers
Core Responsibility: Build and deliver a Done, usable Increment each Sprint while maintaining quality, transparency, and continuous progress.

Scrum Master
Core Responsibility: Ensure Scrum is understood and enacted correctly; coach the team and organization in empiricism, remove impediments, and help improve flow and collaboration.

The Scrum Team is the fundamental unit of Scrum, combining all skills, accountabilities, and authority needed to deliver value through inspection and adaptation.

Persistent: Teams remain stable over time to build trust, rhythm, and continuous improvement.

Owner: Product Owner
Collaborators: Developers refine and estimate; Scrum Master coaches on transparency.

Main Function: The emergent, ordered list of everything needed to improve the product—single source of work for the Scrum Team.

Key Notes:

• Continuously ordered by the Product Owner to maximize value.
• Emergent and continually refined; details, order, and size evolve as more is learned.
• Transparent and visible; items often include description, order, and size (forecast/estimate).
• Represents options and opportunities toward the Product Goal.

Product Goal: The long-term objective for the product. The Product Backlog is a plan to achieve it.

Updated continuously throughout Sprints via Product Backlog Refinement.

To provide transparency, alignment, and an evolving plan that maximizes delivered value.

Owner: Developers (they manage and adjust it)
Collaborators: Product Owner clarifies PBIs; Scrum Master ensures transparency and empiricism.

Main Function: A plan for the Sprint comprised of the Sprint Goal, selected Product Backlog Items, and a plan for delivering the Increment.

Key Notes:

• Created in Sprint Planning; updated daily as more is learned.
• Makes the work visible; enough detail exists to inspect progress in the Daily Scrum.
• Only Developers change the Sprint Backlog; it emerges throughout the Sprint.

Sprint Goal: The single objective for the Sprint, providing focus and flexibility in scope.

Created at Sprint Planning and adapted throughout the Sprint.

To provide a transparent, actionable plan the Developers can inspect and adapt daily to achieve the Sprint Goal.

Timebox-scoped: Exists for the duration of a single Sprint.

Creators: Developers
Notes: Multiple Increments may be created within a Sprint; only “Done” work is part of an Increment.

Main Function: A concrete stepping stone toward the Product Goal—usable, valuable, and meets the Definition of Done.

Key Notes:

• Each Increment is additive to all prior Increments; they work together.
• Work not meeting the Definition of Done is not part of the Increment.
• May be released at any time; at least one Increment is created each Sprint.

Definition of Done (DoD): A formal description of quality for the Increment. It ensures transparency and determines when work is complete.

Created during the Sprint; inspected in the Sprint Review; releasable at any time.

To deliver value, enable inspection, and show progress toward the Product Goal.

Persistent: The sum of Increments accumulates over the product’s lifetime.

Required: Entire Scrum Team
Optional: Stakeholders (as invited during Sprint Review)

Main Function: The container event that includes all other Scrum events and produces a usable Increment.

Key Notes:

• The Sprint may be canceled only by the Product Owner if the Sprint Goal becomes obsolete.
• The Sprint ends when the timebox expires.
• No changes may endanger the Sprint Goal.
• Quality cannot be reduced.
• Scope may be clarified or renegotiated with the Product Owner as more is learned.
• Choosing the length: Balance frequent feedback with ability to deliver a meaningful Increment. Shorter Sprints increase adaptability but add planning overhead.
• Changing the length: May be adjusted between Sprints if it improves effectiveness; never during an active Sprint, and keep consistent thereafter for predictability.

Begins: Immediately after the previous Sprint ends.
Ends: After the Sprint Retrospective.

To create a usable Increment of value and enable continuous inspection and adaptation.

Timebox: One month or less, maintaining a consistent duration for each Sprint.

Required: Product Owner, Scrum Master, Developers
Optional: Subject-matter experts (invited for advice)

Main Function: Define why the Sprint is valuable, what can be done, and how the work will be achieved.

Key Notes:

• Three topics: Why (Sprint Goal), What (forecast of PBIs), How (plan to deliver the Increment).
• Product Owner proposes how value could be increased this Sprint; the Scrum Team crafts a clear Sprint Goal.
• Developers forecast based on capacity, past performance, and Definition of Done; they decompose PBIs as needed.
• Outcome is a transparent Sprint Backlog (Sprint Goal, selected PBIs, plan).

To align the Scrum Team on a clear Sprint Goal and a realistic plan.

Timebox: Up to 8 hours for a one-month Sprint (shorter for shorter Sprints).

Required: Developers
Optional: Others may attend but must not disrupt. Scrum Master ensures it occurs and stays within timebox.

Main Function: Inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours.

Key Notes:

• Focus on outcomes and next steps; the three questions are optional, not required.
• Keep it lightweight: same time and place each day to reduce complexity.
• Developers update the Sprint Backlog as needed to reflect the plan.

To maintain transparency, alignment, and momentum toward the Sprint Goal.

Timebox: 15 minutes.

Required: Scrum Team
Optional: Stakeholders (collaborate on what was done and what to do next)

Main Function: Inspect the outcome of the Sprint (the Increment) and adapt the Product Backlog to maximize value.

Key Notes:

• Discuss what changed in the market or context and potential next steps.
• Demonstrate the Done Increment; gather feedback and new ideas.
• Results in a revised Product Backlog and likely target dates based on progress.

To align with stakeholders on value delivered and next priorities based on evidence.

Timebox: Up to 4 hours for a one-month Sprint (shorter for shorter Sprints).

Required: Scrum Team (internal event)

Main Function: Inspect how the last Sprint went and plan ways to increase quality and effectiveness.

Key Notes:

• Examine people, relationships, processes, tools, and the Definition of Done.
• Identify the most helpful changes and create a plan for improvement.
• At least one improvement is often added to the next Sprint Backlog to ensure progress.
• Items may also be added to the Product Backlog if they represent longer-term improvements or new opportunities for the team.

To establish a culture of continuous improvement and raise quality over time.

Timebox: Up to 3 hours for a one-month Sprint (shorter for shorter Sprints).

Required: Product Owner and Developers
Optional: Scrum Master (facilitates when needed)

Main Function: Continuously add detail, estimates, and order to items in the Product Backlog to ensure upcoming work is well understood and ready for future Sprints.

Key Notes:

• Important: Refinement is not a formal Scrum event. It is an ongoing collaborative activity performed as needed.
• The goal is to keep the Product Backlog healthy, clear, and prioritized.
• May include estimating effort, splitting large PBIs, clarifying requirements, and adjusting order based on value and feedback.
• Developers are responsible for sizing work; the Product Owner ensures clarity and ordering by value.
• Scrum Teams often dedicate up to 10% of their capacity to refinement, but this is flexible.

Occurs throughout the Sprint as needed; not timeboxed or tied to a specific day.

To ensure upcoming Product Backlog Items are well-understood, appropriately sized, and ready for selection in future Sprints.

Timebox: Not fixed. Common guideline: up to 10% of the team’s capacity within the Sprint.