Free PMI Agile Certified Practitioner (PMI-ACP) practice test: 30 questions with answers

Agile values self-organizing teams that take ownership of decisions, so ceremonies without that ownership miss the point. Frequent delivery, rigid practice adherence, and fixed scope each address other aspects of agile work, but none of them explains the passive behaviour described.

The manifesto values documentation but places working software first as the main evidence of progress. Stopping documentation entirely, keeping documents for auditors only, or waiting for complete documents before delivery each misread the intent of the value.

When requirements are uncertain, a short experiment with frequent feedback reduces risk and lets the scope and date adapt to what is learned. Fixed commitments on poorly understood work, waiting for complete requirements, and deferring to the original charter all ignore that uncertainty.

Limiting work in progress and planning realistic capacity let a team keep a steady pace without burnout. Routine overtime, concentrating urgent work on a few people, and lengthening sprints each push pace upward in ways that tend to be unsustainable.

An MVP is the smallest product that delivers real value and produces learning from users, which informs the next increment. A full feature release, a prototype never tested with customers, and a minimum document set each miss the learning purpose.

Value-stream mapping exposes waiting, handoffs, and rework, which are the forms of waste that Lean targets. Large half-finished backlogs, multitasking, and daily status reports create waste rather than remove it.

Automated tests and peer review catch defects early and spread design knowledge, which sustains technical quality. Accepting shortcuts with a promise of later cleanup, deferring refactoring, and keeping design knowledge private all allow technical debt to accumulate.

A growth mindset and psychological safety both let teams learn from failure and surface problems early, which agile depends on. A fixed mindset resists change, a course certificate does not change how a team thinks, and command-and-control leadership slows adaptation.

Discussing the realistic outcome with the product owner and adjusting scope at the next planning keeps the team transparent and respects the timebox. Extending the sprint, declaring success regardless, and adding people midway each break the timebox or misrepresent the result.

Explicit WIP limits per stage reduce multitasking and expose bottlenecks, which is the core of Kanban flow control. Unlimited starts, removing the board, and raising limits whenever queues grow each undermine the limit that gives Kanban its effect.

Velocity is the completed work per iteration, which helps forecast how much the same team can take on. Using hours, defects, or spending to rank or judge teams misuses the measure and ignores that estimates are relative to each team.

Forecasting from recent throughput and showing the range of likely outcomes gives an evidence-based commitment. Committing to everything, taking items regardless of capacity, and doubling hour estimates ignore the team's observed delivery rate.

Splitting the story and re-planning with the product owner keeps the sprint transparent and delivers the most valuable part first. Overtime, silently dropping work, and marking unfinished work as done each hide the problem or break the definition of done.

An automated pipeline that builds, tests, and deploys each change makes releases routine and low-risk. Annual bundled releases, manual approvals for every change, and environments that differ from production each increase the risk and delay of delivery.

Lead time, cycle time, and their variability show how steady delivery is, which is what predictability requires. Hours worked, meeting counts, and lines of code measure effort or activity rather than the flow of finished value.

A shared checklist applied consistently makes done mean the same thing for every item, which is what makes progress reliable. Counting work done before testing, letting each developer define done, and changing the definition after the fact all make progress figures unreliable.

Facilitating a structured conversation addresses the conflict directly and keeps the focus on shared goals and team impact. Removing people, having the product owner adjudicate technical disputes, and deferring to a performance review each avoid the facilitation the situation needs.

A servant leader serves the team by removing impediments, coaching, and shielding it from disruption. Direct instruction, centralized approval, and reporting without team involvement are command-and-control patterns that agile teams avoid.

Making decision norms visible helps newcomers participate, and it reflects shared leadership where the team owns its choices. A single decider, months of silent observation, and informal private routes each keep the newcomer outside the decision process.

A regular review of working increments with a forecast and a list of decisions keeps the sponsor informed and engaged without drowning them in detail. Daily backlog dumps, a single end-of-project summary, and attending every stand-up each create either overload or silence.

A team charter records agreed norms and values so that the team can refer back to them and adjust them as it learns. Fixing tasks, replacing retrospectives, and centralizing change approval each work against the adaptability that the charter supports.

Addressing disagreements early and using a shared decision method keep conflict productive and make the team's choices its own. Hiding disagreement, letting a senior person settle everything, and keeping conflicts private each suppress the learning and ownership that collaboration needs.

Bringing the proposal to the team with evidence keeps the decision shared and gives the team a chance to weigh the risk of a late change. Overruling, recording the developer, and letting changes happen privately each shut down the collaboration that shared leadership depends on.

Value, cost, and risk assessment, revisited as information changes, is the basis for prioritizing a backlog in agile products. Alphabetical order, requester seniority, and entry order are not measures of value.

An agile roadmap communicates direction and intended outcomes and is updated as learning arrives. A fixed multi-year feature commitment, a detailed task list, and a budget record each treat the roadmap as a contract or a ledger rather than a guide.

Weighing the request's value against current priorities keeps the decision transparent and protects the sprint. Accepting without discussion, rejecting without explanation, and adding overtime each damage either trust or the team's sustainable pace.

Observable, measurable conditions let the team and the customer agree on whether the story is done. Criteria left open, written only in internal jargon, or copied from another product do not give a shared, testable definition of success.

Testing the key assumptions with a small experiment or user feedback shows whether the value is real before the cost is committed. Building on an executive request alone, counting mentions, and estimating only cost each skip the value question.

A user story captures who needs what and why in a short, conversational form that invites discussion and refinement. Technical specifications, legal contracts, and test scripts are other artifacts with different purposes.

Weighted scoring against agreed criteria gives a transparent, comparable basis for choices among options. Alphabetical sorting, random selection, and seniority-based priority each ignore value and risk.