Free PSM I Exam Flashcards

Transparency, Inspection, and Adaptation. Work and progress must be visible (transparency) so they can be checked often (inspection) and adjusted quickly when they drift from an acceptable goal (adaptation).

Significant aspects of the process must be visible to everyone responsible for the outcome, using a shared, common understanding (for example, a single Definition of Done) so what is seen equals what is real.

Inspection must be frequent and diligent enough to detect undesirable variances, but not so frequent that it gets in the way of the work itself — the goal is to catch problems early, not to add overhead.

The process or the product being built must be adjusted as soon as possible to minimize further deviation, rather than waiting for a later checkpoint to react.

Commitment, Focus, Openness, Respect, and Courage. Living them builds the trust that makes the three pillars of empiricism actually work.

Openness. The Scrum Team and stakeholders agree to be open about the work and the challenges — silos and hidden problems break the transparency the framework depends on.

Product Owner, Scrum Master, and Developers. The Scrum Guide 2020 calls these 'accountabilities,' not roles, and recognizes no accountabilities beyond these three.

Maximizing the value of the product resulting from the Scrum Team's work, primarily through effective Product Backlog management: developing and communicating the Product Goal, and creating, ordering, and making Product Backlog items transparent.

Establishing Scrum as defined in the Scrum Guide and the overall effectiveness of the Scrum Team. The Scrum Master is a true leader who serves the Scrum Team, the Product Owner, and the organization.

Creating a plan for the Sprint (the Sprint Backlog), instilling quality by adhering to the Definition of Done, adapting their plan daily toward the Sprint Goal, and holding each other accountable as professionals.

Small enough to remain nimble and large enough to complete significant work within a Sprint — typically 10 or fewer people total, counting everyone unless the Scrum Master or Product Owner is also doing Developer work.

No. The Scrum Team is one cohesive unit of professionals focused on one objective at a time, and it is cross-functional and self-managing with no internal sub-teams.

Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The Sprint is the container event that holds all the others.

One month. Shorter Sprints are often used to generate more learning cycles and to limit risk and cost to a smaller time frame.

A new Sprint starts immediately — Sprints are back-to-back with no gap between them.

8 hours. Shorter Sprints usually take proportionally less time, and it is up to the Scrum Team to shorten the event.

Why is this Sprint valuable (the Sprint Goal), What can be Done this Sprint (selected Product Backlog items), and How will the chosen work get done (the plan built by the Developers).

The Developers conduct it — the Scrum Master only ensures it happens. It is a 15-minute event to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, not a status report to the Scrum Master or Product Owner.

4 hours. It is a working session, not a one-way demonstration — the Scrum Team and stakeholders collaborate on what to do next.

The Scrum Team and key stakeholders. They inspect the outcome of the Sprint, discuss progress toward the Product Goal, and adapt the Product Backlog based on what was learned.

3 hours, and it is the last event of the Sprint — it concludes the Sprint by inspecting how the last Sprint went regarding people, interactions, processes, tools, and the Definition of Done.

Only the Product Owner has the authority to cancel a Sprint, although they may be influenced by stakeholders, the Scrum Master, or the Developers before deciding.

Product Backlog, Sprint Backlog, and Increment. Each of the three artifacts carries exactly one commitment.

The Product Goal — it describes a future state of the product that the Scrum Team can use as a long-term target to plan against, and the team focuses on one Product Goal at a time.

The Sprint Goal — the single objective for the Sprint, crafted during Sprint Planning, that gives the Developers flexibility on exact scope while keeping the team coherent and focused.

The Definition of Done — the formal description of the state the Increment must meet to be considered complete, ensuring transparency about the work's quality.

The Product Owner alone. They may delegate the actual work of ordering to others, including Developers, but remain accountable for the result.

It cannot be released or even presented as Done at the Sprint Review — it returns to the Product Backlog for future consideration, with no partial credit given.

The Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how) — all created and owned by the Developers.

The Scrum Team creates a Definition of Done appropriate for the product, but it must still be compatible with any organizational standards or conventions that already exist.

'Self-managing' — Scrum Teams decide internally who does the work, how to do it, and what to work on, rather than being directed by someone outside the team.

'Developers' — the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint, with no internal sub-roles or hierarchy among them.

The team possesses all the skills necessary to create value each Sprint, without needing to rely on people outside the team to get the work done.

Coach the manager and organization on self-management — the team, not an outside manager, decides who works on what. The Scrum Master helps remove that organizational barrier.

Psychological safety, built from living the Scrum Values — especially Openness and Respect — which enables honest transparency instead of hidden issues.

Serving the Scrum Team, serving the Product Owner, and serving the organization — each with distinct coaching and facilitation responsibilities.

Teaching explains Scrum theory and practice to people unfamiliar with it. Coaching grows the team's own capability to solve problems and improve, rather than solving issues for them.

The Scrum Master does not have to personally solve every blocker — they ensure impediments get removed, escalating outside the team's control when the team cannot resolve it alone.

Guiding a group process, such as an event or a difficult conversation, toward a useful outcome while staying neutral on the content — not directing the decision itself.

Coach the Product Owner on backlog management and value-maximization techniques — the Scrum Master supports the Product Owner's decisions rather than taking over the ordering.

The long-term objective for the Scrum Team, describing a future state of the product that the Product Backlog exists to serve. The team commits to only one Product Goal at a time.

It is a dynamic list that is never complete — it only becomes more precise over time as the product, its market, and the team's understanding evolve.

Refinement is the ongoing act of breaking down and adding detail to Product Backlog items so they are ready for future Sprints. It is not a formal, prescribed Scrum event — it happens continuously.

Just one of each — one shared Product Backlog, one Product Owner, and one Definition of Done across all teams working on that product.

Yes, including to Developers, but the Product Owner remains accountable for the outcome regardless of who performs the work.

Velocity is a tool the Developers use for their own Sprint forecasting and planning. A common misuse is applying it to measure, rank, or compare individual people rather than team-level planning.

An evidence-based projection built from past empirical performance data — not a fixed promise or a guaranteed delivery date.

Primarily the Product Owner decides. A Done Increment may be released at any time and does not have to wait until the Sprint Review to reach customers.

To inspect the outcome of the Sprint, gather feedback, and adapt the Product Backlog to maximize future value — not to serve as a pass/fail approval gate for the work.

The value delivered to customers and stakeholders and progress toward the Product Goal — not simply completing planned tasks or maximizing velocity.