Agile frameworks are structured ways of working that help teams deliver small, valuable pieces of a project quickly and then adapt based on feedback. They replace the old assumption that you can predict everything upfront. For the CAPM exam, you need to understand the core principles and the main frameworks — because the exam will test whether you know which framework does what, and which mindset underpins them all.
Jump to a section
A simple way to picture Introduction to Agile Frameworks
A busy community kitchen, early Saturday morning. Four of you have volunteered to bake 200 cupcakes for a school fete. You could use a traditional recipe: measure everything precisely, preheat the oven to exactly 180°C, and bake all 200 in one massive batch. But that takes hours, and if the first batch burns, you've wasted everything.
Instead, you choose an agile approach. You gather for a five-minute huddle (a daily stand-up) and decide: 'Let's bake a dozen vanilla cupcakes first, taste them, and see what happens.' You bake a small batch, ice them, and offer a taste to a passer-by. 'Too sweet,' they say. 'Could we get chocolate instead?' So you adjust the batter immediately. You bake another dozen, this time chocolate. A child asks for sprinkles. You add sprinkles to the next batch. Each small batch (a sprint) takes just 15 minutes. After each batch, you look at what you've learned and change the next batch. By lunchtime, you've made 200 perfect cupcakes, each improved by the previous one. Your 'traditional recipe' friends, who baked all 200 at once, have a pile of burnt, overly sweet cupcakes that nobody wants. That, in a nutshell, is the difference between a rigid, up-front plan and an agile, adaptive method.
Agile is not a single method; it is a mindset based on the Agile Manifesto, a document published in 2001 by a group of software developers who were frustrated with rigid, slow project management. The Manifesto contains four values and twelve principles. The four values are: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Notice the word 'over' — the Manifesto does not say the right-hand side is bad. It says the left-hand side is more important.
The twelve principles include: early and continuous delivery of valuable work, welcoming changing requirements, delivering work frequently (every few weeks), and having business people and developers work together daily. These principles guide every agile framework.
The three most common frameworks you need to know for CAPM are Scrum, Kanban, and extreme Programming (XP).
Scrum is a structured framework that organises work into fixed-length cycles called Sprints, typically one to four weeks long. The team has three key roles: the Product Owner (who decides what to build and in what order), the Scrum Master (who helps the team follow Scrum rules and removes blockers), and the Developers (who do the actual work). Each Sprint starts with Sprint Planning, where the team picks a set of small tasks from the Product Backlog (a prioritised to-do list). Every day, the team meets for a 15-minute Daily Scrum or stand-up to answer three questions: What did I do yesterday? What will I do today? What blockers do I have? At the end of the Sprint, the team holds a Sprint Review (to show what they built) and a Sprint Retrospective (to talk about how to improve the process).
Kanban is less structured than Scrum. It focuses on visualising work and limiting work in progress (WIP). The key tool is a Kanban board with columns like 'To Do', 'In Progress', and 'Done'. Each task is a card that moves from left to right. The rule is: no more than three tasks can be in 'In Progress' at once. This prevents the team from starting too many things at once and finishing nothing. Kanban does not have fixed cycles or roles; it is a continuous flow system.
eXtreme Programming (XP) is a framework that emphasises technical excellence. It includes practices like Pair Programming (two developers at one computer), Test-Driven Development (writing a test before writing code), Continuous Integration (merging code changes frequently), and Small Releases (releasing updates often). XP is popular when quality and speed are critical.
All these frameworks share a common foundation: they value delivering small, working increments, gathering feedback, and adjusting quickly. They contrast with the traditional Waterfall approach, where you complete one big phase (requirements, design, build, test) before moving to the next. Waterfall works well when the problem is fully understood upfront. Agile works better when requirements are uncertain or likely to change.
For the CAPM exam, remember that 'agile' is the umbrella term. Agile is the mindset. Scrum, Kanban, and XP are specific frameworks you can use to implement that mindset. The exam loves to test whether you can identify which framework matches a given scenario, and whether you know the roles and events of Scrum.
Embrace the Agile Mindset
Before learning any framework, understand that agile values individuals and interactions, working product, customer collaboration, and responding to change. This mindset underpins everything. Without it, the frameworks are just empty rituals.
Create a Product Backlog
The Product Owner builds a prioritised list of all the features or work items needed. Each item is written as a user story with a clear value statement. The backlog is never finished; it evolves as new information emerges.
Plan a Sprint (if using Scrum)
In Sprint Planning, the team selects a subset of backlog items they can complete in a fixed time period (e.g., two weeks). They break items into tasks, estimate effort, and commit to a Sprint goal. This step converts a long-term list into an actionable short-term plan.
Execute the Work in Small Batches
The team works on the selected tasks, meeting daily for the Daily Scrum to coordinate and identify blockers. They aim to complete each task fully before moving to the next, ensuring a potentially shippable increment at the end of the Sprint.
Inspect and Adapt via Sprint Review and Retrospective
At the end of the Sprint, the team shows the working product to stakeholders in the Sprint Review and gathers feedback. Then, in the Sprint Retrospective, the team reflects on their own process and commits to improvements for the next Sprint. This continuous improvement loop is the engine of agility.
Imagine a small team at a retail company building a new mobile app for customers to track loyalty points. The team has a Product Owner, a Scrum Master, and three Developers. They decide to use Scrum.
First, the Product Owner creates a Product Backlog: a list of features like 'log in with email', 'view points balance', 'earn points on purchases', and 'redeem points for vouchers'. Each feature is written as a user story, for example: 'As a customer, I want to log in with my email so I can see my points.' The Product Owner ranks the stories by business value.
The team holds Sprint Planning for a two-week Sprint. They pick three user stories from the top of the backlog and break them down into smaller tasks. They estimate effort using story points (a unit of effort). They commit to completing those three stories by the end of the Sprint.
During the two weeks, the team meets every morning for a 15-minute Daily Scrum. One developer says, 'I finished the login screen today; I will start the points database; I am blocked by waiting for the security review from IT.' The Scrum Master takes note of the blocker and helps resolve it.
At the end of the Sprint, they hold a Sprint Review. They show the working login feature to the Product Owner and a few real customers. The customers give feedback: 'The login page takes too long to load; can we add fingerprint login?' The team adds those requests to the backlog.
Finally, they hold a Sprint Retrospective. The team members discuss what went well (they finished all three stories), what could improve (the task estimation was off by 20%), and what they will change next Sprint (use shorter tasks).
If this team used Kanban instead, they would have a board with columns and strict limits on how many tasks could be in progress. They would pull new tasks only when capacity opened up, without fixed Sprints. If they used XP, they would pair up for coding and write tests before writing any code.
In real IT work, professionals often combine frameworks. A team might use Scrum for their ceremonies but add Kanban's WIP limits to manage the board. The CAPM exam expects you to recognise these practices as part of the agile ecosystem.
The CAPM exam tests your understanding of the agile mindset and the specific frameworks, not your ability to be a practitioner. The questions are typically scenario-based. You are given a short description of a project situation and asked to identify the best framework, role, or practice to use.
Common traps:
They will ask you to choose between Scrum and Kanban. Remember: Scrum has fixed-length Sprints and specific roles (Product Owner, Scrum Master, Developers). Kanban has no fixed Sprints, no prescribed roles, and focuses on limiting work in progress.
They will try to confuse you with the term 'Iteration' (a synonym for Sprint in many contexts). In Scrum, an Iteration is a Sprint. In Kanban, iterations do not exist.
They will ask about the Agile Manifesto values. The key trap: people remember the left-hand side but forget the right-hand side is not worthless. For example, a question might say 'Agile means you never write documentation'. That is false. The Manifesto says 'working software over comprehensive documentation' — you still write documentation, just not a huge amount upfront.
They will test the difference between a Product Owner and a Project Manager. In agile, the Product Owner decides what to build (the 'what' and the priority), while the Scrum Master facilitates the process. The Project Manager role is often distributed across the team.
Key definitions to memorise:
Agile Manifesto: the four values and twelve principles.
Sprint: a time-boxed period (typically 2-4 weeks) during which work is completed.
Daily Scrum: a 15-minute daily meeting to inspect progress and adapt.
Sprint Retrospective: a meeting at the end of a Sprint to improve the process.
Product Backlog: a prioritised list of all desired work.
Sprint Backlog: the subset of the Product Backlog selected for a specific Sprint.
Kanban board: a visual management tool with columns and WIP limits.
WIP limit: the maximum number of tasks allowed in a particular column at once.
The exam also tests your understanding of the 'agile mindset' as distinct from the framework. A question might say: 'Which of the following best exemplifies the agile mindset?' The correct answer will involve embracing change, delivering value early, and collaborating with customers — not following a rigid plan.
Finally, be able to identify which framework is best suited to a scenario. If the scenario emphasises continuous delivery and requires tight quality and safety (like medical software), XP is likely the answer. If the scenario focuses on visual workflow management and reducing bottlenecks, Kanban is the answer. If the scenario involves fixed time boxes and defined roles, Scrum is the answer.
Agile is a mindset based on four values and twelve principles from the Agile Manifesto, not a single method.
Scrum uses fixed-length Sprints, three roles (Product Owner, Scrum Master, Developers), and specific ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective).
Kanban visualises work on a board and limits work in progress, but has no fixed roles or time-boxes.
extreme Programming (XP) focuses on technical excellence through practices like pair programming and test-driven development.
The Product Owner prioritises the Product Backlog; the Scrum Master facilitates the process; the Developers build the product.
Agile welcomes changing requirements, even late in the project, because short feedback cycles reduce risk.
Waterfall is a sequential, plan-driven approach; agile is an iterative, adaptive approach; both can be appropriate depending on the project type.
These come up on the exam all the time. Here's how to tell them apart.
Scrum
Has fixed-length time-boxed Sprints (e.g., 2 weeks).
Has defined roles: Product Owner, Scrum Master, Developers.
Uses Sprint Planning, Daily Scrum, Sprint Review, Retrospective.
Kanban
No fixed iterations; work flows continuously.
No prescribed roles; team decides how to organise.
No prescribed ceremonies; relies on visual board and WIP limits.
Agile
Iterative and incremental delivery.
Welcomes changing requirements even late in the project.
Customer collaboration throughout the project.
Waterfall
Sequential phases (requirements, design, build, test).
Changes are difficult and expensive once a phase is complete.
Customer involvement mainly at the start and end.
Product Owner
Owns the Product Backlog.
Prioritises features based on business value.
Makes decisions about what the team builds.
Scrum Master
Owns the Scrum process.
Facilitates events and removes blockers.
Coaches the team on agile principles.
Mistake
Agile means you don't plan anything and just start coding.
Correct
Agile involves planning, but at a different level. You plan the current Sprint or iteration in detail, and have a high-level plan for the future that you adjust as you learn.
The word 'agile' sounds like 'move fast without planning', and many beginners assume it means no planning at all. In reality, agile is about adaptive planning, not absence of planning.
Mistake
Scrum and Agile are the same thing.
Correct
Agile is a broad mindset and set of principles. Scrum is one specific framework that implements that mindset. There are many other agile frameworks (Kanban, XP, Lean, etc.).
Scrum is the most widely used agile framework, so people often use 'Scrum' and 'Agile' interchangeably. The CAPM exam specifically tests the distinction.
Mistake
A Product Owner is just the project manager by another name.
Correct
A Product Owner is responsible for maximising the value of the product and managing the Product Backlog. A project manager typically coordinates resources, budget, and scope across the whole project. In agile, the role of a project manager is often distributed among the team.
Beginners see 'someone who decides what to build' and think 'that's the boss, which is the project manager'. But the roles have different accountabilities.
Mistake
You cannot use Kanban if you have fixed deadlines.
Correct
Kanban can be used with deadlines. You can set a service level expectation (SLE) that predicts how long a task will take. Kanban does not forbid deadlines; it just does not prescribe fixed cycles.
Because Kanban is often described as 'continuous flow', people think it cannot accommodate time constraints. In practice, you can use Kanban with a deadline by controlling WIP limits.
Mistake
Agile frameworks are only for software development.
Correct
Agile values and frameworks have been successfully applied to marketing, construction, event planning, and even manufacturing. The key is that the work can be broken into small increments and benefits from feedback.
The Agile Manifesto was created by software developers, so the examples are mainly software. Many people assume it only applies to IT. The CAPM exam may test general project management knowledge, so you need to know agile is not industry-specific.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In Scrum, a Sprint is a specific time-boxed iteration (usually 1-4 weeks). The term 'Iteration' is often used synonymously with Sprint, but 'iteration' is a general term for any repeating cycle, while 'Sprint' is specifically a Scrum term.
No. Agile frameworks originated in software development but are now used in many industries, including marketing, construction, and event management. The core principles of delivering value incrementally and adapting to feedback work wherever work can be broken into small chunks.
The Sprint ends on schedule. Unfinished tasks are returned to the Product Backlog for re-prioritisation. The team analyses why they did not finish and adjusts their commitment for the next Sprint. This is normal and part of the learning process.
Yes, many teams use 'Scrumban', which blends Scrum's roles and events with Kanban's WIP limits and board visualisation. The CAPM exam expects you to understand each framework individually, but real-world practise often mixes them.
Neither is universally better. Waterfall works well when requirements are stable and the scope is clear. Agile works well when requirements are uncertain or likely to change. A skilled project manager chooses the approach that best fits the project context.
Know the Agile Manifesto values and principles, the three main frameworks (Scrum, Kanban, XP), and which key practices belong to which framework. Focus on scenarios: the exam will ask you to pick the right framework or role for a given situation.
You've finished Introduction to Agile Frameworks. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?