ACP-520 cheat sheet
ACP-520 · Keep the key ideas within reach.
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.
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.
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.
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.
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.
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.
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.
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.