ACP-520 key terms

A short 2001 statement of four values and twelve principles that prioritize individuals, working software, customer collaboration, and responsiveness to change over rigid process and documentation.

A leadership stance in which the person in charge removes obstacles, coaches, and protects the team rather than directing tasks, so the team can self-organize and deliver value.

A way of managing work through frequent inspection and adaptation of transparent, observable facts rather than following a fixed plan, suited to complex problems with unpredictable outcomes.

A lightweight framework in which a small cross-functional team delivers increments of value in fixed-length sprints, using defined roles, events, and artifacts to inspect and adapt.

A flow-based method that visualizes work on a board, limits how much work is in progress, and manages throughput and cycle time to improve delivery predictability.

An engineering-focused Agile approach built on short iterations, test-driven development, pair programming, continuous integration, and frequent small releases.

A fixed-length timebox, usually one to four weeks, during which the team builds a usable increment of product while keeping scope stable and goals clear.

A single sentence describing the outcome the team intends to achieve in the current sprint, giving focus and a basis for deciding what work to include.

An ordered, evolving list of everything that might be built into the product, with the highest-value items at the top and details refined as work approaches.

The subset of backlog items selected for a sprint plus the team's plan for delivering them, owned and adjusted by the developers as they work.

The concrete, usable output produced during a sprint that meets the definition of done and adds to the product's overall value.

A shared checklist describing what must be true for work to count as complete, ensuring everyone applies the same quality standard to every increment.

A brief description of a need written from the user's perspective, often in a role-goal-benefit format, that invites conversation and supports incremental delivery.

Specific, testable conditions a story must satisfy to be accepted by the product owner, clarifying scope and forming the basis for verification.

A quality checklist for stories: independent, negotiable, valuable, estimable, small, and testable, used to judge whether an item is ready for a sprint.

A large body of related work that is too big to complete in one iteration and is progressively broken down into smaller stories for delivery.

A technique that arranges user activities and stories along a horizontal journey and slices releases vertically, helping teams plan meaningful increments rather than isolated features.

An ongoing activity where the team and product owner clarify, split, estimate, and reorder upcoming backlog items so they are ready when needed.

A relative unit of effort used to size backlog items by comparison rather than by hours, capturing complexity, uncertainty, and volume together.

A consensus estimation technique in which each team member privately selects a card representing a size, then discusses differences until the group converges.

The average amount of estimated work a team completes per iteration, used for short-term forecasting and trend spotting rather than as a performance target.

A line graph showing work remaining versus time within an iteration or release, revealing progress trends and scope changes at a glance.

A chart that plots completed work rising against a line for total scope, making it easy to see both progress and additions to the work.

A stacked area chart showing how many items sit in each workflow state over time, exposing bottlenecks, work in progress, and lead time trends.

The elapsed time from when work starts on an item to when it is finished, a core flow measure for predicting how quickly items will be delivered.

The total elapsed time from when a request is made or an item enters the system until it is delivered to the customer.

The number of work items completed in a given period, used to forecast how much can be delivered and to evaluate flow improvements.

A cap on how many items may occupy a workflow stage at once, which reduces multitasking and surfaces bottlenecks so flow improves.

The role accountable for maximizing product value by ordering the backlog, clarifying requirements, and making trade-off decisions visible to the team.

The role responsible for coaching the team and organization on the framework, facilitating events, and removing impediments so the team can perform.

A group that decides internally how to divide and sequence its work, holding collective accountability for outcomes rather than waiting for assigned tasks.

A team that collectively holds all the skills needed to deliver a working product increment without depending on outside groups for each step.

Any obstacle blocking the team's progress that the team cannot resolve alone and that is raised for removal, often tracked visibly on a board.

A short daily team meeting to inspect progress toward the sprint goal and adapt the plan for the next day, not a status report to a manager.

An end-of-sprint session where the team demonstrates the increment to stakeholders, gathers feedback, and adapts the backlog based on what is learned.

A facilitated end-of-sprint meeting where the team reflects on how it worked together and commits to specific, actionable improvements for the next iteration.

A sustained practice of inspecting how work is done, identifying small changes, and embedding them so quality and effectiveness rise over time.

Anyone with an interest in or influence over the product, such as customers, sponsors, or support staff, whose needs and feedback shape priorities.

A highly visible display, such as a task board or chart, placed where the team and passersby can see current status without asking anyone.

Uncontrolled growth of requirements during delivery that erodes predictability and quality because it is accepted without adjusting time, cost, or capacity.

The accumulated cost of shortcuts and design compromises that makes future changes harder, repaid through deliberate refactoring and quality work.

Improving the internal structure of code without changing its external behavior, keeping the codebase easy to modify as requirements evolve.

A practice where developers merge small changes frequently into a shared mainline, with automated builds and tests catching integration problems early.

A cycle of writing a failing test first, then the minimal code to pass it, then refactoring, which drives design and builds a safety net.

Allocating a fixed maximum amount of time to an activity and ending it when time expires, which forces prioritization and keeps cadence predictable.

A forward-looking outline of which features or outcomes are expected in upcoming releases, used to align stakeholders while remaining open to change.

A high-level view of intended product direction and outcomes over time, communicating sequence and intent rather than fixed dates and detailed scope.

A specific, owned, and time-bound improvement the team commits to after a retrospective or review, tracked until it is done.