COPR ACP key terms

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

Building a product in short repeated cycles, where each cycle adds a usable slice of functionality and allows earlier assumptions to be corrected before more work is committed.

A management approach that maximizes customer value by identifying which activities create value, removing waste, limiting work in progress, and improving flow continuously.

A visual exercise that traces the steps a request passes through, marking where time is spent waiting versus working, so teams can target the largest sources of delay.

A cap on how many items may be in a given stage at once, used to expose bottlenecks, shorten queues, and encourage the team to finish work before starting more.

A habit of small, continuous, team-driven improvements to process and working conditions, applied regularly rather than through occasional large restructuring efforts.

A fixed, non-extendable period allocated to an activity such as a meeting or iteration, which encourages focus and forces trade-off decisions when scope would otherwise expand.

The steady rhythm of planning, review, and retrospective events across iterations, giving stakeholders predictable points to inspect progress and adjust direction.

Prioritizing and sequencing work by the benefit it delivers to customers and the organization, so the highest-value items are completed and validated as early as possible.

The smallest set of functionality that delivers meaningful, usable value to a customer segment, allowing early release and learning without building the whole vision.

A version of a product with just enough capability to test key assumptions with real users, built to gather evidence rather than to satisfy every anticipated requirement.

The act of ordering backlog items by value, risk, cost, and dependency so the team always works on the most worthwhile item available within current constraints.

A ranking method that divides the value of an item by its duration and other cost factors, favoring short high-value items so economic benefit arrives sooner.

The expected benefit of a piece of work compared with its cost, used to justify funding decisions and to compare competing candidate features or projects.

Identifying everyone affected by or interested in the product, then recording their influence, interest, and concerns so engagement effort can be targeted appropriately.

A lightweight plan describing which stakeholders need what information, in which format, at which intervals, and who is responsible for each interaction.

An agreed schedule and set of channels for sharing progress, decisions, and risks with specific audiences, adjusted as the project and its stakeholders change.

A highly visible, easy-to-read display of current status such as a task board or burn chart, placed where the team and passers-by see it without asking anyone.

A representative description of a typical user type, including goals and frustrations, used to keep design and prioritization decisions focused on real customer needs.

A leadership stance in which the leader's main job is removing obstacles, providing resources, and developing people so the team can make decisions and deliver.

A group that decides how to divide and sequence its own work, within agreed boundaries, rather than waiting for a manager to assign tasks and methods.

A team whose members collectively hold the skills needed to take an item from idea to delivered result, reducing handoffs and external dependencies.

A profile where a person has deep expertise in one area and working competence across several related areas, enabling flexible reallocation of work within the team.

A short document the team writes for itself covering purpose, values, working agreements, decision rules, and escalation paths, used to resolve friction later.

Explicit norms the team chooses about how members will behave and collaborate, such as review turnaround or meeting conduct, which can be revisited when they stop helping.

Helping individuals and the team improve through questioning, feedback, and practice rather than by giving instructions or solving their problems for them.

Planning at multiple horizons with just enough detail for the near term, revising forecasts as new information arrives instead of defending an outdated baseline.

Detailing near-term work precisely while leaving later work at a coarse level, refining it progressively as the horizon approaches and uncertainty falls.

A forward look that maps prioritized features to one or more upcoming releases, balancing value, capacity, dependencies, and market timing.

The average amount of estimated work a team completes per iteration, used as a short-term forecasting input rather than as a performance target or comparison across teams.

A relative unit of size used to estimate backlog items, capturing effort, complexity, and uncertainty without pretending to be a precise measure of elapsed time.

A group estimation technique where members privately choose a size card, reveal simultaneously, and discuss outliers until the team converges on a shared estimate.

The ongoing activity of clarifying, splitting, re-estimating, and reordering upcoming backlog items so they are ready when the team has capacity to start them.

The practice of making work, risk, and defects visible early through charts, reviews, and tests, then resolving root causes rather than repeatedly patching symptoms.

Any obstacle blocking the team's progress, such as a missing decision, environment, or person, which is logged, owned, and driven to removal quickly.

Raising an issue to a level with authority or resources to resolve it, following an agreed path and time threshold rather than waiting indefinitely.

A stacked chart of item counts per stage over time, whose widening bands reveal growing queues and bottlenecks before they show up as missed dates.

A relationship stating that average items in a system equal arrival rate multiplied by average time in the system, used to predict how limiting work in progress shortens lead time.

The elapsed time from when work starts on an item to when it is finished, a key flow measure for forecasting and for judging process improvements.

A structured investigation, such as repeated asking why or a fishbone diagram, that identifies the underlying reason a defect or delay occurred so it can be prevented.

The combined discipline of raising delivered quality through built-in technical practices while steadily improving how the team works, using evidence rather than opinion.

A shared checklist describing what must be true for an item to count as complete, including quality criteria, so that finished work needs no later rework.

Conditions written for a specific backlog item that must be satisfied for the customer or product owner to accept it as meeting the intended need.

An agreed checklist indicating an item is clear, estimated, testable, and free of blocking dependencies, so the team can start it without further negotiation.

The future cost of shortcuts in design or code that make later change slower, tracked and repaid deliberately rather than allowed to accumulate silently.

Improving the internal structure of existing code without changing its external behavior, keeping the design easy to modify as understanding grows.

A cycle of writing a failing automated test first, then the simplest code to pass it, then refactoring, which yields a safety net and drives design decisions.

Merging each change into a shared mainline frequently and running automated builds and tests, so integration problems surface within minutes rather than weeks.

Two people working together at one workstation, one writing and one reviewing, swapping roles often to spread knowledge and catch defects while they are cheap.

A regular team meeting to inspect how work was done, identify causes of friction, and commit to a small number of concrete improvements to try next iteration.

An ordering of work that places high-value, high-uncertainty items early so that risky assumptions are tested while there is still time to change course.

A short, timeboxed investigation built to answer a specific technical or product question and reduce uncertainty before committing to delivery work.

A living list of identified risks with likelihood, impact, owner, and planned response, reviewed regularly so responses are acted on rather than filed away.

An external rule, standard, or contractual obligation the product must satisfy, which should be expressed as testable acceptance criteria and verified within each iteration.

A short statement of a need written from a user's perspective, with a goal and a reason, intended to prompt conversation rather than to serve as a full specification.

A visible grid of columns representing workflow stages, with cards moving across as work progresses, making status and bottlenecks obvious at a glance.

A line chart showing remaining estimated work against time within an iteration, used to spot a flat trend early and discuss causes rather than to pressure the team.

Addressing disagreement directly and early by focusing on interests and evidence, choosing an approach suited to the stakes, and preserving the relationship.