ACP-520 study materials
ACP-520 study resources

ACP-520 cheat sheet

ACP-520 · Keep the key ideas within reach.

Quick reference

Agile Values and Principles

  • The four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.

  • The right-hand items in the four values are not worthless; the statement is a priority ordering when the two sides conflict.

  • Twelve principles include: satisfy the customer through early and continuous delivery of valuable software.

  • Principles include welcoming changing requirements, even late in development, for the customer's competitive advantage.

  • Principles include delivering working software frequently, with a preference for the shorter timescale.

  • Principles include business people and developers working together daily throughout the project.

  • Principles include building projects around motivated individuals, giving them the environment and support they need, and trusting them to get the job done.

  • Principles include that working software is the primary measure of progress and that simplicity (maximizing the amount of work not done) is essential.

  • Principles include self-organizing teams producing the best architectures, requirements, and designs, and teams reflecting at regular intervals on how to become more effective.

Quick reference

Agile Frameworks and Practices

  • Scrum defines three accountabilities (Product Owner, Scrum Master, Developers), five events, and three artifacts (Product Backlog, Sprint Backlog, Increment).

  • The five Scrum events are Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; the Sprint is the container for the other four.

  • Scrum artifacts each have a commitment: Product Backlog to Product Goal, Sprint Backlog to Sprint Goal, Increment to Definition of Done.

  • The Daily Scrum is a 15-minute event for Developers, held at the same time and place, to inspect progress toward the Sprint Goal.

  • Kanban practices: visualize the workflow, limit work in progress, manage flow, make policies explicit, and improve collaboratively.

  • Extreme Programming core practices include pair programming, test-driven development, continuous integration, small releases, and collective code ownership.

  • SAFe organizes work at Team, Program (Agile Release Train), Large Solution, and Portfolio levels, with PI Planning as a recurring cadence event.

  • Scrumban combines Scrum's roles and cadence with Kanban's WIP limits and pull-based flow.

Quick reference

Agile Team Roles and Responsibilities

  • The Product Owner maximizes product value and is accountable for effective Product Backlog management, including ordering items and ensuring the backlog is transparent and understood.

  • The Scrum Master is accountable for the Scrum Team's effectiveness, coaching the team and the organization, and removing impediments; the role is not a project manager or a command authority.

  • Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint; they self-manage and decide how to turn backlog items into value.

  • The Scrum Team is cross-functional and typically ten or fewer people; there are no sub-teams or hierarchies within it.

  • In XP the Coach guides the team on process, and the On-site Customer supplies requirements and priorities.

  • A Kanban team uses service classes (for example standard, expedited, fixed date) to define policies for handling different work items.

  • A servant-leader removes impediments and shields the team from interference rather than assigning tasks.

  • A RACI matrix assigns Responsible, Accountable, Consulted, and Informed; each row should have exactly one Accountable.

Quick reference

Agile Planning and Estimation

  • Story points estimate relative size (effort, complexity, uncertainty), not elapsed time; they are unitless and team-specific.

  • Velocity = sum of story points of items completed to the Definition of Done in a Sprint; average over several Sprints for forecasting.

  • Expected Sprints to finish remaining work = remaining story points / average velocity.

  • Planning poker is a consensus technique using a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20, 40, 100).

  • Affinity estimation groups similar items by relative size before assigning numbers.

  • The product roadmap orders work by value and risk; release planning selects backlog scope for a target outcome or date.

  • A Sprint Goal is a single objective for the Sprint; Sprint Backlog scope may be negotiated with the Product Owner as more is learned.

  • Cone of Uncertainty: estimates are least precise early and narrow as knowledge grows; refine estimates as work approaches.

Quick reference

Agile Project Delivery and Execution

  • The Definition of Done is a shared, explicit checklist that an Increment must satisfy; an item is not complete until it meets it.

  • Continuous integration requires developers to merge to a shared mainline frequently, with automated build and test on each merge.

  • Test-driven development cycle: write a failing test, write the minimum code to pass, then refactor.

  • Refactoring improves internal design without changing external behavior; it is a continuous practice, not a phase.

  • A timebox is a fixed maximum duration for an event or activity; when time expires the event ends, which forces focus.

  • A spike is a short, timeboxed investigation to reduce technical or requirements uncertainty before estimating or building.

  • Impediments are raised at the Daily Scrum and tracked by the Scrum Master until resolved.

  • Incremental delivery means each Sprint produces a potentially releasable, usable Increment rather than a partial build only at the end.

Quick reference

Stakeholder Engagement and Communication

  • The Sprint Review is a working session with stakeholders to inspect the Increment and adapt the Product Backlog; it is not merely a demo or a status report.

  • Information radiators (burndown charts, Kanban boards, CI status) display information publicly so passers-by can see it without asking.

  • An osmotic communication environment lets team members overhear relevant information without formal meetings.

  • The Product Owner is the single point of contact for product decisions and backlog ordering, protecting the team from conflicting direction.

  • A big visible chart makes progress and problems visible to the whole organization.

  • Feedback loops include daily coordination, Sprint Reviews, and retrospectives; shorter loops reduce the cost of correcting course.

  • Stakeholder mapping plots influence against interest to decide who needs close collaboration versus periodic updates.

  • A shared workspace or co-located team reduces communication friction; distributed teams must add explicit channels to replace hallway conversations.

Quick reference

Agile Metrics and Continuous Improvement

  • A burndown chart plots remaining work over time within a Sprint; a burnup chart plots completed work and total scope and reveals scope changes.

  • Velocity measures completed points per Sprint and is used for forecasting, not for comparing teams.

  • Cycle time = time from work started to work finished; lead time = time from request made to work delivered.

  • Little's Law: average items in progress = arrival rate x average cycle time; it supports flow and WIP-limit reasoning.

  • Cumulative flow diagrams show WIP as the vertical band between lines; a widening band signals a bottleneck.

  • Throughput = number of items completed per unit time; it is a flow metric that does not depend on point estimates.

  • A retrospective examines what went well, what did not, and what to change; it should produce a small number of owned, tracked actions.

  • A kaizen or improvement experiment should be small, measurable, and timeboxed so its effect can be evaluated.

Quick reference

Agile Metrics and Continuous Improvement

  • Defect escape rate measures defects found after release relative to total defects found; a rising rate signals quality-process gaps.

  • Code coverage is a diagnostic, not a goal; high coverage does not prove test effectiveness.

  • The retrospective prime directive asks the team to assume everyone did the best job they could given their knowledge and resources.

  • A 5 Whys analysis repeatedly asks why to move from a symptom to a root cause.

  • An improvement backlog holds retrospective actions and is reviewed like any other backlog so actions are not dropped.

  • Escaped-defect and cycle-time trends are more useful than single data points; compare against the team's own baseline.

  • A blocker or impediment log tracks time-to-resolution as a flow health indicator.

  • Team health checks (for example a short anonymous survey each retrospective) track morale and psychological safety over time.