PECB Certified PSM Basic key terms

A lightweight framework in which a small cross-functional team turns work into valuable increments through short, fixed-length cycles, guided by three accountabilities, five events, and three artifacts.

The principle that knowledge comes from observation and experience, so decisions are based on what is actually known and verified rather than on forecasts, plans, or assumptions.

The first pillar of empiricism: the process, its state, and the work being done are visible to the people accountable for the outcome, using a shared and understood standard.

The second pillar of empiricism: the artifacts and progress toward agreed goals are examined frequently enough to detect undesirable variance without disrupting the work itself.

The third pillar of empiricism: when inspection reveals that one or more aspects of the process deviate beyond acceptable limits, the process or the work is adjusted as soon as possible.

Five commitments that shape behavior and build trust: commitment, focus, openness, respect, and courage. Teams live them in their work, their communication, and their decisions.

A team that internally decides who does what, when, and how, rather than being directed by someone outside the team; it holds the authority to organize its own work toward the product goal.

A small group of people, typically ten or fewer, consisting of one Scrum Master, one Product Owner, and Developers, with all skills needed to deliver a valuable increment each sprint.

The single accountable person for maximizing product value, who develops and communicates the product goal, orders the product backlog, and decides what the team works on next.

The accountable person for the team's effectiveness, who coaches the team and organization in Scrum practice, removes impediments, and serves as a true leader without command authority.

Any member of the Scrum Team who creates the increment each sprint, regardless of job title, and who shares accountability for quality, technical decisions, and the Definition of Done.

A leadership stance in which the Scrum Master puts the needs of the team and its customers first, coaching, facilitating, and removing obstacles rather than directing or controlling the work.

Helping people improve through questions, reflection, and feedback rather than instructions; a core Scrum Master activity aimed at building capability that lasts beyond one problem.

Designing and guiding group interactions so that participants can reach shared understanding and decisions, while the facilitator stays neutral about content and keeps the purpose visible.

Any obstacle that slows or blocks the team's progress and that the team cannot resolve on its own; the Scrum Master helps ensure such obstacles are surfaced and addressed.

A fixed-length iteration of one month or less in which a usable, potentially releasable increment is created; it is the container for all other Scrum events.

The first event of the sprint, where the team agrees why the sprint is valuable, what can be delivered, and how the work will be done, producing a sprint goal and a sprint backlog.

A fifteen-minute event for the Developers, held every working day of the sprint, to inspect progress toward the sprint goal and adapt the plan for the next day of work.

An event near the end of the sprint where the team and stakeholders inspect the increment, discuss progress toward the product goal, and adapt the product backlog.

The final event of the sprint, where the team inspects how it worked and identifies the most useful improvements to its process and collaboration, some of which may enter the next sprint backlog.

A short statement of the single objective for the sprint that gives the team focus and coherence; it is agreed during planning and may be renegotiated with the Product Owner as learning occurs.

A long-term objective describing a future state of the product that the team works toward across several sprints; it gives direction to the product backlog and its ordering.

One of the three tangible things Scrum defines to represent work or value: the product backlog, the sprint backlog, and the increment. Each carries a commitment that supports transparency.

An emergent, ordered list of what is needed to improve the product, owned by the Product Owner; its top items are the most understood and ready for near-term work.

A plan composed of the sprint goal, the selected product backlog items, and the actionable plan for delivering the increment; it is updated daily as more is learned.

The concrete, usable step toward the product goal produced during a sprint. It must meet the Definition of Done and adds to all previous increments.

A shared, explicit checklist of quality criteria that an increment must satisfy to be considered complete; it makes transparency real and prevents unfinished work from being counted as done.

The ongoing activity of breaking down, clarifying, and re-estimating product backlog items so that upcoming work is small enough and understood well enough to be selected in planning.

A short, plain-language description of a need written from the user's perspective, commonly in a who-what-why form, used as a conversation starter rather than a full specification.

The conditions a product backlog item must satisfy to be accepted by the Product Owner, often expressed as testable scenarios that complement, but do not replace, the Definition of Done.

A team's observed rate of completing backlog items per sprint, measured against its Definition of Done; useful as a short-term planning input, never as a target or performance measure.

A relative unit used to size backlog items by effort, complexity, and uncertainty together; values are meaningful only within one team and are not comparable across teams.

A consensus estimation technique in which team members privately choose a card for an item, reveal simultaneously, and discuss differences until agreement is reached.

A fixed maximum duration for an activity, such as fifteen minutes for the Daily Scrum, that creates a regular rhythm and forces prioritization instead of open-ended discussion.

A visual display of the sprint backlog, often organized in columns that reflect the team's workflow, used to make work and its flow transparent to the team and stakeholders.

A line chart showing work remaining against time in a sprint or release, used by the team to inspect progress; trends matter more than exact values.

An optional team agreement describing what a backlog item should look like before it is brought into sprint planning, such as being small, testable, and understood by the team.

A recurring practice that looks helpful but undermines Scrum, such as treating the Daily Scrum as a status report to a manager or letting the Scrum Master assign tasks.