Agile Methodology Cheat Sheet

Updated 2026-07-17

Next Topic: Agile Metrics and KPIs Cheat Sheet

🎯Take a practice test on this topic7 practice tests · 208 questions→

🧠Study flashcards on this topic156 cards · spaced repetition→

Agile Methodology is a software development philosophy rooted in the 2001 Agile Manifesto, emphasizing iterative delivery, customer collaboration, and adaptive planning over rigid processes. Born from the need to respond rapidly to changing requirements, Agile shifted the industry from waterfall's sequential approach to incremental value delivery through short cycles called sprints or iterations. The key mental model: working software delivered frequently beats comprehensive documentation and distant deadlines, so teams inspect, adapt, and continuously improve both product and process. In 2026, Agile has expanded far beyond software into business agility, with scaling frameworks, AI-integrated delivery, and outcome-focused metrics reshaping how organizations adopt it.

What This Cheat Sheet Covers

This topic spans 21 focused tables and 165 indexed concepts, 156 flashcards, 7 practice tests with 208 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core ValuesTable 2: Core PrinciplesTable 3: Agile FrameworksTable 4: Scrum Accountabilities (Roles)Table 5: Scrum Events (Ceremonies)Table 6: Scrum Artifacts and CommitmentsTable 7: Kanban PracticesTable 8: User Stories and RequirementsTable 9: Estimation TechniquesTable 10: Agile MetricsTable 11: Scaling FrameworksTable 12: Extreme Programming (XP) PracticesTable 13: Lean PrinciplesTable 14: Retrospective TechniquesTable 15: Agile Planning LevelsTable 16: Team CharacteristicsTable 17: Advanced ConceptsTable 18: Continuous PracticesTable 19: Agile TransformationTable 20: Backlog Prioritization TechniquesTable 21: Anti-Patterns and Pitfalls

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Values

The four value statements of the 2001 Agile Manifesto are the bedrock everything else rests on. Each one is a trade-off, not a rejection: the Manifesto closes by saying that while there is value in the items on the right, its authors value the items on the left more. Processes, documentation, contracts, and plans all still count, they just lose the tie-break.

Value	Example	Description
Individuals and interactions over processes and tools	A five-minute conversation settles a design question vs. a week of comments on a ticket	Treats people and communication as the main driver of success, with process and tools supporting the team rather than steering it
Working software over comprehensive documentation	Shipping a feature users can try this week vs. a 90-page spec describing it	Ranks software that actually runs above exhaustive documents, which the authors kept but trimmed down to what stays useful
Customer collaboration over contract negotiation	The client reshapes the next two weeks at a review vs. both sides re-reading the signed scope	Builds a partnership with customers where ongoing feedback shapes the product more than the agreed terms do
Responding to change over following a plan	Reworking the roadmap when a competitor's launch shifts what customers need	Keeps the plan serving reality, since the authors plan but accept that planning has limits when things keep moving

Table 2: Core Principles

If the four values are the spirit of Agile, these twelve principles are the concrete guidance that turns spirit into behavior. They cover how often you deliver, how you treat changing requirements, how the team works together, and how it sustains itself over time. The wording below follows the canonical text at agilemanifesto.org, which is worth checking against any summary you meet elsewhere, because these principles get misquoted constantly.

Principle	Example	Description
Satisfy the customer through early and continuous delivery	Releasing an MVP in 4 weeks, then iterating monthly	The Manifesto's highest priority, and valuable is the load-bearing word: frequency only counts if the customer receives something worth having

The rest of this section is part of the full cheat sheet

Table 3: Agile Frameworks

Agile is an umbrella, not a single recipe. These are the concrete frameworks teams actually adopt to put it into practice, ranging from prescriptive (Scrum's fixed events and accountabilities) to flow-based (Kanban's continuous delivery), engineering-heavy (XP), and enterprise-scale (SAFe). Many teams blend them, as Scrumban does, so knowing what each one optimizes for is the first step to picking the right fit.

Framework	Example	Description
Scrum	Cross-functional team of 10 or fewer delivering a product Increment every 2 weeks	• Lightweight framework using fixed-length Sprints, three accountabilities (Scrum Master, Product Owner, Developers), and five prescribed events • founded on empiricism and lean thinking

The rest of this section is part of the full cheat sheet

Table 4: Scrum Accountabilities (Roles)

Scrum defines just three accountabilities: one person who owns what gets built, one accountable for the team's effectiveness, and the people who build it. The 2020 Scrum Guide renamed "roles" to "accountabilities" to stress that these are responsibilities rather than job titles, so one person can hold more than one, and a healthy Scrum Team needs all three clearly held.

Role	Example	Description
Product Owner	Ordering the Product Backlog from customer feedback and value, and deciding what the team builds next	• Accountable for maximizing product value resulting from the work of the Scrum Team • develops and communicates the Product Goal, creates and orders Product Backlog items, and may delegate that work while remaining accountable; is one person, not a committee, whose decisions the organization must respect

The rest of this section is part of the full cheat sheet

Table 1: Core Values

Value	Example	Description
Individuals and interactions over processes and tools	A five-minute conversation settles a design question vs. a week of comments on a ticket	Treats people and communication as the main driver of success, with process and tools supporting the team rather than steering it
Working software over comprehensive documentation	Shipping a feature users can try this week vs. a 90-page spec describing it	Ranks software that actually runs above exhaustive documents, which the authors kept but trimmed down to what stays useful
Customer collaboration over contract negotiation	The client reshapes the next two weeks at a review vs. both sides re-reading the signed scope	Builds a partnership with customers where ongoing feedback shapes the product more than the agreed terms do
Responding to change over following a plan	Reworking the roadmap when a competitor's launch shifts what customers need	Keeps the plan serving reality, since the authors plan but accept that planning has limits when things keep moving

Table 2: Core Principles

Principle	Example	Description
Satisfy the customer through early and continuous delivery	Releasing an MVP in 4 weeks, then iterating monthly	The Manifesto's highest priority, and valuable is the load-bearing word: frequency only counts if the customer receives something worth having

Table 3: Agile Frameworks

Framework	Example	Description
Scrum	Cross-functional team of 10 or fewer delivering a product Increment every 2 weeks	• Lightweight framework using fixed-length Sprints, three accountabilities (Scrum Master, Product Owner, Developers), and five prescribed events • founded on empiricism and lean thinking

Table 4: Scrum Accountabilities (Roles)

Role	Example	Description
Product Owner	Ordering the Product Backlog from customer feedback and value, and deciding what the team builds next	• Accountable for maximizing product value resulting from the work of the Scrum Team • develops and communicates the Product Goal, creates and orders Product Backlog items, and may delegate that work while remaining accountable; is one person, not a committee, whose decisions the organization must respect