PSD flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Empiricism

The theory that knowledge comes from experience and decisions from what is observed. Scrum applies it through transparency, inspection, and adaptation so plans update as reality emerges.

Three pillars of Scrum

Transparency, inspection, and adaptation. Transparency makes work visible, inspection checks progress toward goals, and adaptation adjusts process or work when deviation is found.

Sprint timebox

A Sprint is a fixed container of one month or less. Fixed length creates a predictable cadence for inspection and limits risk to the cost of one Sprint.

Sprint Goal

A single objective for the Sprint agreed during Sprint Planning. It guides the Developers' work and provides flexibility on the specific backlog items needed to achieve it.

Product Goal

The commitment attached to the Product Backlog. It describes a future state of the product that guides long-term planning and gives the backlog a target.

Sprint cancellation

Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete. Completed Done items are reviewed; incomplete ones return to the Product Backlog.

Scrum values

Commitment, focus, openness, respect, and courage. They shape how the team works and are used to evaluate whether Scrum's empirical pillars are actually functioning.

Scrum Team size

One Scrum Team is ten or fewer people total, including Product Owner and Scrum Master. Larger groups split into multiple teams sharing one Product Backlog and Product Goal.

Definition of Done

A formal description of the quality state required for the Increment. Work not meeting it is not Done and cannot be released or shown as part of the Increment.

Continuous integration

Merging every change into the shared mainline frequently and verifying with an automated build and test run. It keeps the Increment genuinely releasable and makes progress transparent.

Test-driven development cycle

Red, green, refactor: write a failing test for the next behavior, write the minimum code to pass it, then refactor while all tests stay green.

Refactoring

Improving internal code structure without changing observable behavior. It preserves the ability to change direction each Sprint without accumulating unmanageable design debt.

Trunk-based development

Developers integrate to a shared mainline using short-lived branches lasting hours to a day. It surfaces integration conflicts early instead of at the end of the Sprint.

Automated regression suite

Tests that re-verify existing behavior after each change. They are the safety net enabling continuous integration and aggressive refactoring without silent breakage.

Technical debt visibility

Debt taken on deliberately must appear in the Product Backlog so the Product Owner can trade it against features. Hidden debt destroys the ability to forecast and to stay releasable.

Vertical slice

A thin piece of functionality delivered end to end across all layers. It can satisfy the Definition of Done and produce a usable Increment within a single Sprint.

Pair programming

Two developers working at one station, one writing and one reviewing, swapping roles. It spreads knowledge across the team and reduces reliance on any single specialist.

Definition of Done floor

When multiple teams work on one product, they share a common Definition of Done. It may be stricter than organizational standards but never weaker than them.

Developers accountability

Developers commit to creating any aspect of a usable Increment each Sprint. They own the Sprint Backlog, the technical how, and the quality of the work delivered.

Self-managing Developers

The Developers decide internally who does what, when, and how. Neither the Product Owner nor the Scrum Master assigns tasks or dictates technical approach.

Cross-functional team

The team collectively holds every skill needed to produce a Done Increment. It does not require each individual to possess every skill.

Daily Scrum purpose

A 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is not a status report to management.

Collective code ownership

Any developer may change any part of the codebase. It prevents knowledge silos and gatekeeping, which would undermine the team's self-managing, cross-functional premise.

Scrum Master accountability

Establishing Scrum as defined in the Scrum Guide by coaching the team and organization. The Scrum Master serves the team; they do not direct the Developers' work.

Product Owner accountability

Maximizing product value by managing and ordering the Product Backlog. The Product Owner sets the what and the why; the Developers decide the how.

Sprint Backlog ownership

The Developers own the Sprint Backlog, which contains the Sprint Goal, selected Product Backlog items, and the plan for delivering them. Only Developers update it during the Sprint.

Increment

The sum of completed, usable work from the current and prior Sprints. It must meet the Definition of Done and be in a state where release is possible.

Potentially releasable Increment

Each Sprint must produce an Increment the Product Owner could choose to release immediately. Producing it is mandatory; actually releasing it is a separate business decision.

Multiple Increments per Sprint

An Increment is delivered whenever work becomes Done, so several may appear within one Sprint. There is no rule requiring a single delivery at Sprint end.

Sprint Review outcome

The Sprint Review inspects the Increment and adapts the Product Backlog. Its result is a revised backlog that informs the next Sprint Planning, not just a demonstration.

Undone work handling

Work that does not meet the Definition of Done is not part of the Increment. It returns to the Product Backlog and is re-ordered and re-estimated by the Product Owner.

Velocity as planning aid

A rough measure of past throughput used only to forecast future capacity. It is not a target or a performance metric imposed on the Developers.