PMI-ACP key terms

A 2001 statement of four values and twelve principles that favor individuals, working software, customer collaboration, and response to change over heavier documentation, contracts, and rigid plans. Most agile frameworks build on it as a shared foundation.

A way of managing work in which decisions rest on what is actually observed rather than on forecasts alone. It depends on transparency, frequent inspection, and quick adaptation when results drift from expectations.

A leadership stance in which the person in charge focuses on removing obstacles, developing people, and meeting the team's needs so the team can deliver. Authority is used to support rather than to command.

A group that decides for itself how to divide and sequence its work within agreed boundaries and goals. Managers set direction and constraints, while the team chooses the approach and owns the result.

A team that collectively holds every skill needed to take an item from idea to delivered result, so work does not queue between separate specialist groups. Members may still specialize but share accountability for the outcome.

Information that reaches team members simply because they share the same physical space and overhear conversations. It reduces formal handoffs and delays, but only works when people are co-located.

Explicit norms a team writes for itself covering how members communicate, decide, handle conflict, and treat one another. They are created collaboratively and revisited when they stop helping.

A model describing group development as forming, storming, norming, performing, and later adjourning. Teams typically move from polite uncertainty through conflict toward stable collaboration, and leaders adjust their style at each stage.

The ability to notice and manage one's own feelings and to read and respond to other people's. In agile settings it supports constructive conflict, honest retrospectives, and effective coaching conversations.

A conflict approach that separates people from the problem and searches for options that satisfy each side's underlying interests instead of splitting stated positions. It aims at outcomes both parties will commit to.

A short, plain-language statement of a need written from the user's perspective, usually naming the role, the goal, and the benefit. It is a placeholder for a conversation rather than a full specification.

Fictional but research-based profiles of typical users describing their goals, context, and frustrations. Teams use them to keep design and prioritization discussions anchored on real customer needs.

A highly visible display placed where the team and passers-by will see it, showing status such as progress, blockers, or quality trends. It communicates without anyone needing to ask or schedule a meeting.

Identifying who is affected by or can influence the product, then mapping them by interest and influence to plan engagement. Common outputs include a power-interest grid and a communication plan.

A working session at the end of an iteration where the team demonstrates completed, usable product to stakeholders and gathers feedback. It is a two-way inspection of the product, not a status report.

An ordered list of everything that might be built, with the highest-value items at the top and finer detail near the front. It is continuously reshaped as learning and feedback accumulate.

The ongoing activity of reviewing upcoming backlog items to add detail, split large ones, re-estimate, and reorder them. Done regularly, it keeps planning sessions short and options open.

A unitless measure of relative size, complexity, and uncertainty used to estimate backlog items. Because it is comparative rather than clock-based, it is meaningful mainly within a single team.

A group estimation technique in which each member privately selects a card showing a size value, then the team discusses differences until estimates converge. It reduces anchoring and surfaces hidden assumptions.

Fixing a maximum duration for an activity so that scope, not the deadline, flexes. It creates a predictable cadence and forces early decisions about what matters most.

The amount of backlog work a team completes per iteration, expressed in its own estimation units. It is a planning aid for that one team and is never a fair basis for comparing teams.

A line graph showing work remaining against time within an iteration or release. Its slope and deviations prompt conversations about scope, blockers, or the quality of estimates.

A short, timeboxed investigation built to answer a technical or design question so the team can estimate and plan with less uncertainty. It produces knowledge, and its output is not shippable functionality.

Planning in detail only for the near term while keeping later work at a high level, then elaborating it as the horizon approaches. It suits environments where requirements are expected to change.

The smallest slice of functionality that delivers real value to customers and can be released on its own. Teams use it to split large ideas so value arrives early rather than at the end.

Ordering work by the value it returns, whether revenue, risk reduction, learning, or cost avoidance, rather than by who asked loudest or by ease of building. It keeps delivery focused on outcomes.

A way of classifying features by how their presence or absence affects satisfaction: basic expectations, performance features, and delighters. It helps teams avoid over-investing in features customers barely notice.

A backlog in which the value of each item is weighed against the risk it carries, so high-risk or high-uncertainty work is pulled forward while uncertainty is cheapest to resolve.

A cap on how many items may be in progress at one stage at the same time. It exposes bottlenecks, encourages finishing over starting, and shortens the time work spends in the system.

The elapsed time from when work actually starts on an item to when it is finished. Tracking it reveals how long items really take and where queues slow the flow.

A relationship stating that the average number of items in progress equals throughput multiplied by the average time in the system. It explains why cutting work in progress shortens waiting time.

A stacked area chart showing how many items sit in each state over time. Widening bands reveal growing queues or bottlenecks, while the slope of the top line shows throughput.

Repeatedly asking why a problem occurred until the underlying cause rather than a symptom is exposed, often through a five-whys exercise. Teams then fix the cause and verify the fix worked.

A graph plotting total remaining risk exposure against time, updated as risks are retired and new ones appear. A flat line signals that risk-reduction work is not actually happening.

A recurring, facilitated meeting in which the team examines how it worked, identifies what to change, and commits to a small number of improvements. Its value depends on follow-through between sessions.

An agreed checklist describing what must be true for an item to count as complete, such as tested, reviewed, and documented. It stops partial work from being reported as finished.

The future cost created by choosing a quick or expedient solution now instead of a better one, which slows later changes. Teams track it and repay it deliberately rather than by surprise.

A practice in which developers merge small changes into a shared codebase frequently, with automated build and tests verifying each merge. It catches integration problems while they are still cheap to fix.

A diagram of the steps work passes through, showing where time is spent waiting versus being actively worked on. Teams use it to find delays and waste worth removing.