PSD key terms

A lightweight framework for developing complex products. It uses fixed-length Sprints, three accountabilities, five events, and three artifacts to enable empiricism and frequent delivery.

The philosophy that knowledge comes from experience and decisions are based on what is observed. In Scrum, transparency, inspection, and adaptation make this practical.

Making the process, work, and artifacts visible to those doing and receiving the work. It requires a common standard so observers share the same understanding.

Frequent, careful examination of Scrum artifacts and progress toward agreed goals. Inspection detects undesirable variance and must not disrupt the work being inspected.

Adjusting the process, product, or plans when inspection reveals deviation or better options. It is performed as soon as possible to minimize further deviation.

A fixed-length iteration of one month or less in which a usable, potentially releasable Increment is created. It contains all other Scrum events and is the heartbeat of Scrum.

A concise statement of the single objective for the Sprint. It gives the team focus and flexibility, and is created during Sprint Planning by the Developers.

The first event of the Sprint, where the team defines why the Sprint is valuable, what can be done, and how the work will be accomplished. It is timeboxed to eight hours for a one-month Sprint.

A 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is held at the same time and place each working day.

An event at the end of the Sprint to inspect the Increment and adapt the Product Backlog. It is a working session for the team and stakeholders, timeboxed to four hours for a one-month Sprint.

The final event of the Sprint, where the team inspects how the last Sprint went regarding individuals, interactions, processes, tools, and Definition of Done. It identifies improvements for the next Sprint.

An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team and is refined continuously.

A plan by and for the Developers consisting of the Sprint Goal, the selected Product Backlog items, and the plan for delivering them. It is updated throughout the Sprint as more is learned.

A concrete, usable step toward the Product Goal. Each Increment is additive to prior Increments and must meet the Definition of Done to be considered releasable.

A formal description of the state of the Increment when it meets the quality measures required for the product. It creates transparency and is agreed upon by the Scrum Team.

A long-term objective for the Scrum Team that describes a future state of the product. It provides a target for planning and is found in the Product Backlog.

The accountability for maximizing product value by managing and ordering the Product Backlog. This person represents stakeholder needs and ensures the backlog is clear and understood.

The accountability for establishing Scrum as defined in the Scrum Guide and for the team's effectiveness. This person serves the team and organization by removing impediments and coaching.

The people in the Scrum Team who create the Increment each Sprint. They are cross-functional, self-managing, and accountable for the Sprint Backlog and quality.

A small team consisting of one Scrum Master, one Product Owner, and Developers. It is cross-functional and self-managing, with no sub-teams or hierarchies.

A team that internally decides who does what, when, and how. In Scrum, the team chooses how to best accomplish work rather than being directed by outsiders.

A team with all the skills necessary to create value each Sprint. This reduces dependencies on people outside the team and enables end-to-end delivery.

The ongoing activity of breaking down and further defining Product Backlog items so they are ready for selection in Sprint Planning. It is not a formal Scrum event.

A fixed maximum duration for an activity or event. In Scrum, events are timeboxed to create focus and prevent excessive discussion.

An Increment that meets the Definition of Done and could be delivered to users if the Product Owner chooses. It is produced at least once per Sprint.

The implied cost of rework caused by choosing an easy solution now instead of a better approach. It should be made transparent and managed in the Product Backlog.

A development practice where tests are written before code. It drives design, provides fast feedback, and supports emergent design and continuous refactoring.

A practice where developers integrate code into a shared mainline frequently, usually multiple times a day. Each integration is verified by an automated build and tests.

A practice that keeps software in a deployable state at all times. It enables frequent, reliable releases and supports delivering a potentially releasable Increment each Sprint.

A disciplined technique for restructuring existing code without changing its external behavior. It improves design and is a key practice for managing technical debt.

An approach where design evolves incrementally as the team learns, rather than being fully specified upfront. It relies on practices like refactoring and TDD.

A team's shared criteria for when a Product Backlog item is ready to be selected in Sprint Planning. It is a complementary practice, not part of the Scrum Guide.

Anything that blocks or slows the Developers from completing work. The Scrum Master helps remove impediments, though the team may also resolve them.

A measure of how much Product Backlog work a team completes per Sprint, often in story points. It is a planning aid, not a performance metric or a goal.

A relative unit of measure for estimating the size and complexity of Product Backlog items. It is not a measure of time and is team-specific.

A visual graph showing work remaining versus time in a Sprint. It helps the team inspect progress but is not a required Scrum artifact.