How do you manage a project when the requirements change every week, or even every day? That's the problem that Agile frameworks like Scrum solve, and it matters because the CAPM exam will test whether you know the specific roles, time-boxed events, and key documents that make this approach work.
Jump to a section
A simple way to picture Agile Roles, Events, and Artifacts
Before you set off on a long family road trip, someone has to decide the destination and pick the route. That's the Product Owner. Then, someone has to make sure everyone packs the right clothes and snacks, and that the car has enough fuel. That's the Scrum Master. And you, the driver, along with your siblings in the back seat, are the Development Team, responsible for actually doing the driving and navigating.
Once you start driving, you don't just keep going for 10 hours without stopping. You pull over at a rest stop every two hours or so. That rest stop is a Sprint Review. The family huddles around the map, looks at how much distance you've covered, and decides if you're still heading in the right direction. Maybe the original plan was to visit a museum, but everyone is tired, so you decide to head straight to the hotel instead. That's the adaptation part of the review.
Right after that, before anyone gets back in the car, you have a quick team meeting at the picnic table. That's the Sprint Retrospective. You ask, "Did we argue too much? Should we use a different playlist next time? Did anyone forget to refill the water bottles?" It's about improving the process, not the destination. Finally, every morning before you start driving, you have a 15-minute huddle, the Daily Scrum, where each person says, "I'll drive the first shift, I'll navigate the next 50 miles, and I'm worried about the traffic around the city." The artifacts are the physical items: the printed map (the Product Backlog), the list of snacks you bought at the last stop (the Sprint Backlog), and the pile of candy wrappers in the footwell (the Increment).
Let's start from the very beginning. Traditional project management, often called Waterfall, works like a carefully planned train journey. You figure out the entire route, buy all the tickets, and pack your bags months in advance. If a track is closed or you decide you want to visit a different city, you're stuck. Agile is the opposite. It's like using a taxi service where you can tell the driver to turn left or right as you go. Agile is a set of principles for creating software and other products in a way that welcomes change.
Scrum is the most popular framework for putting Agile principles into practice. It's not a methodology; it's a lightweight process framework. Think of it as the rulebook for a game. The game has specific players (roles), specific time slots (events), and specific equipment (artifacts).
The Three Roles
First, there's the Product Owner. This is one person, not a committee. The Product Owner is the single voice of the customer. They are responsible for maximising the value of the product the team builds. Their main tool is the Product Backlog, which is a ranked list of everything that might be needed in the product. The Product Owner decides what goes on the list and in what order it should be worked on. They are the 'what' and the 'why'.
Second, there's the Development Team. This is a cross-functional group of people who do the actual work of creating the product. They might include software developers, designers, writers, or anyone with the skills needed to turn an idea into a working piece of the product. The Development Team is self-organising, which means no one outside the team tells them how to turn the Product Backlog into a usable product. They are the 'how'.
Third, there's the Scrum Master. This person is not a project manager in the traditional sense. They don't give orders. Instead, they are a servant-leader and a coach. The Scrum Master ensures the Scrum framework is understood and followed. They remove obstacles that block the team's progress, like getting approval for a new server or resolving a conflict between team members. They protect the team from outside interference.
The Five Events (Ceremonies)
Scrum uses time-boxed events to create regularity and minimise the need for meetings not defined in Scrum. Every event has a maximum duration.
The Sprint: This is the heartbeat of Scrum. A Sprint is a time-box of one month or less during which a 'done', useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort.
Sprint Planning: This event kicks off the Sprint. The entire Scrum team (Product Owner, Development Team, Scrum Master) collaborates to decide what work will be done during the Sprint. They select items from the Product Backlog and create a plan for how to complete them. The output is the Sprint Backlog.
Daily Scrum: This is a 15-minute time-boxed event for the Development Team. It's held every day of the Sprint. The team inspects progress toward the Sprint Goal and adapts the plan for the next 24 hours. It's not a status update for the manager; it's a planning meeting for the team.
Sprint Review: Held at the end of the Sprint, this event is where the team shows what they have accomplished. The Product Owner updates the Product Backlog based on feedback from stakeholders. It's a working session, not a formal presentation. The team demonstrates the Increment and discusses what went well and what problems arose.
Sprint Retrospective: This occurs after the Sprint Review and before the next Sprint Planning. The team inspects how the last Sprint went regarding people, relationships, process, and tools. They identify what went well and what could be improved, and they create a plan for implementing improvements during the next Sprint.
The Three Artifacts
Artifacts represent work or value. They are designed to maximise transparency of key information.
Product Backlog: An ordered list of everything that is known to be needed in the product. It is dynamic; it changes constantly as the product and the environment evolve. Items at the top are more detailed and ready to be worked on.
Sprint Backlog: The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realising the Sprint Goal. It is the development team's forecast of what functionality will be in the next Increment and the work needed to deliver that functionality.
Increment: The sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be 'done', which means it must be in a useable condition and meet the team's Definition of Done.
Form the Scrum Team
Identify the three roles: one Product Owner, one Scrum Master, and a cross-functional Development Team. This establishes the single authority for requirements (Product Owner), the process guardian (Scrum Master), and the doers (Development Team).
Create the Product Backlog
The Product Owner writes down every feature, requirement, and fix needed in the product, then orders them by priority. This artifact gives the team a transparent, prioritised list of all possible work.
Hold Sprint Planning
The whole Scrum team meets to decide which Product Backlog items will be tackled in the upcoming Sprint. The team creates the Sprint Goal and the Sprint Backlog, committing to a specific set of deliverables.
Execute the Sprint with Daily Scrums
The Development Team self-organises to complete the Sprint Backlog items. Each morning, they hold a 15-minute Daily Scrum to synchronise, plan the next 24 hours, and identify any impediments the Scrum Master must remove.
Conduct the Sprint Review
At the end of the Sprint, the team demonstrates the working Increment to stakeholders. The Product Owner updates the Product Backlog based on feedback, ensuring the product evolves according to real user needs.
Run the Sprint Retrospective
The team inspects how the Sprint went in terms of people, process, and tools. They identify concrete improvements to implement in the next Sprint, continuously enhancing their way of working.
Meet Priya, a CAPM-certified project coordinator at a mid-sized retail company. Her company is building a new mobile app for customers to track loyalty points. The project has been running for a year with a rigid waterfall plan, and they're behind schedule because customers keep asking for features that weren't in the original requirements. The IT director tells Priya to switch to Scrum.
Priya's first action is to identify the three roles. She finds a business analyst named Raj who has a deep understanding of customer needs and appoints him as the Product Owner. Raj immediately starts building the Product Backlog. He writes down everything customers want: 'view points balance', 'scan receipt for points', 'redeem rewards', and 'see purchase history'. He ranks 'view points balance' as the top priority because customers are calling the support line about it every day.
Next, Priya identifies the Development Team. She selects five people: three software developers, one tester, and one UI designer. She tells them they are now self-organising, meaning they decide among themselves who writes which code. She introduces the team to a developer named Chen who will serve as the Scrum Master. Chen's first task is to set up the events.
Chen creates a two-week Sprint calendar. For the first Sprint Planning, the whole team sits down. Raj explains the top five items in the Product Backlog. The team asks clarifying questions—'How do we define a receipt scan?'—and then estimates the effort required. They commit to completing three items: 'view points balance', 'login screen', and 'scan receipt for points'. They write these on sticky notes and put them on a physical whiteboard, creating their Sprint Backlog.
Each morning at 9:15 AM, the team holds the Daily Scrum. They stand around the whiteboard for exactly 15 minutes. One developer says, 'I finished the login screen yesterday, today I'll work on the points database connection, and I'm blocked because I don't have access to the points server.' Chen, the Scrum Master, immediately emails the IT infrastructure team to unblock the access.
After two weeks, they hold the Sprint Review. They invite the marketing director and two actual customers. The developers show a working prototype of the login and points balance screen on a phone. The customers say, 'It looks good, but can you also show the points expiry date?' Raj updates the Product Backlog with this new request.
Finally, they have the Sprint Retrospective. The team talks about what went well: 'We communicated well'—and what to improve: 'We need a better way to test on real phones.' They agree to buy a test phone for the office. This cycle repeats every two weeks, allowing the team to adapt quickly.
What Priya actually does as a CAPM-certified professional is:
She facilitates the Scrum Master to schedule the events and ensures they stay within their time-boxes.
She tracks the Definition of Done—a checklist the team created that says 'code reviewed, tested, approved by Product Owner'—to ensure every Increment is truly complete.
She updates a burn-down chart that shows how much work remains in the Sprint.
She helps Raj prioritise the Product Backlog by using business value and risk analysis.
She reports progress to the director by pointing to the working software demonstrated in each Sprint Review, not by showing Gantt charts.
The CAPM exam, particularly for exam objective 3.2, tests your ability to identify, differentiate, and apply the Scrum roles, events, and artifacts. It does not ask you to justify Agile philosophy; it asks you to know the mechanics.
What They Love to Test
Ownership of the Product Backlog: The exam will repeatedly ask: 'Who is responsible for ordering the Product Backlog?' The answer is always the Product Owner. A common trap is to say 'the stakeholders' or 'the project manager'. The Product Owner is the single accountable party.
The Daily Scrum is for the Development Team: A frequent question: 'Who must attend the Daily Scrum?' The answer is the Development Team. The Scrum Master can attend but is not required. The Product Owner can attend but is not required. The classic trap question is 'The project manager attends the Daily Scrum to check on progress'—that is wrong.
The Sprint Review is a working session, not a report-out: The exam will present a scenario where the team gives a slide presentation at the Sprint Review. The correct answer is that this is incorrect. The Sprint Review is for inspecting the Increment and adapting the Product Backlog. It is a working session.
The Definition of Done: The exam tests that the Development Team creates the Definition of Done. If not, the Scrum Master helps them. It is never imposed from outside, like by a PMO or a department head.
Time-boxes are rigid: Questions about how long events last are common. Know these: Sprint (one month or less), Sprint Planning (eight hours for a one-month Sprint, proportionally less for shorter Sprints), Daily Scrum (15 minutes), Sprint Review (four hours for a one-month Sprint), Sprint Retrospective (three hours for a one-month Sprint).
Artifact transparency: The exam loves to ask: 'Which artifact lists the work to be done in the Sprint?' The Sprint Backlog. 'Which artifact is the ordered list of everything?' The Product Backlog.
Common Exam Traps
'The Scrum Master manages the team' is wrong; the team is self-organising.
'The Product Owner is a project manager' is wrong; the role is distinct.
'Stakeholders are part of the Scrum team' is wrong; the Scrum team is Product Owner, Development Team, and Scrum Master only.
'The Sprint Review and Sprint Retrospective are the same event' is wrong; they have different purposes (inspect product vs. inspect process).
Exact Concepts to Memorise
The three roles: Product Owner, Scrum Master, Development Team.
The five events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
The three artifacts: Product Backlog, Sprint Backlog, Increment.
The 'product owner' is one person, not a committee.
The 'Scrum Master' is a servant-leader, not a manager.
The 'development team' is cross-functional and self-organising.
The 'sprint goal' is a single objective for the Sprint.
The 'daily scrum' is for the development team to plan the next 24 hours.
The 'sprint review' focuses on the product; the 'sprint retrospective' focuses on the process.
The 'increment' must be 'done' according to the team's Definition of Done.
The three Scrum roles are Product Owner (owns the 'what'), Development Team (owns the 'how'), and Scrum Master (enables the process).
The Sprint is a time-box of one month or less during which a 'done', useable Increment is created.
The Daily Scrum is a 15-minute planning event for the Development Team, not a status report to management.
The Product Backlog is an ordered, living list of everything needed in the product, owned by the Product Owner.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus the plan to deliver them.
The Increment must be 'done' according to the team's Definition of Done, and it must be useable and potentially releasable.
The Sprint Review focuses on the product outcome; the Sprint Retrospective focuses on team process improvement.
The Development Team is self-organising, meaning no one outside the team tells them how to do their work.
These come up on the exam all the time. Here's how to tell them apart.
Product Owner
Responsible for maximising value of the product
Owns and orders the Product Backlog
Decides 'what' the team builds
Scrum Master
Responsible for ensuring Scrum is understood and enacted
Owns the Scrum process, not the product requirements
Decides 'how' the team follows the framework and removes obstacles
Sprint Backlog
Contains items selected for the current Sprint only
Created during Sprint Planning and updated daily by the Development Team
Includes the plan for delivering the Increment and realising the Sprint Goal
Product Backlog
Contains all known work for the product over its entire life
Created and continuously refined by the Product Owner throughout the project
Is an ordered list; no plan for delivery is included
Sprint Review
Focuses on the product outcome and adapting the Product Backlog
Involves stakeholders and the full Scrum team
Time-boxed to four hours for a one-month Sprint
Sprint Retrospective
Focuses on the team's process and how to improve it
Involves only the Scrum team (no external stakeholders)
Time-boxed to three hours for a one-month Sprint
Increment
The sum of all completed Product Backlog items from the Sprint and all previous Sprints
Must be 'done' according to the Definition of Done
Is the output of the Sprint, demonstrated at the Sprint Review
Sprint Backlog
The plan and selected items for the current Sprint only
Includes work that is not yet done; it's a forecast
Is the input to the Sprint, created during Sprint Planning
Mistake
The Scrum Master is like a project manager who assigns tasks to the team.
Correct
The Scrum Master is a servant-leader who coaches the team and removes obstacles; the team is self-organising and assigns tasks to itself.
Beginners associate any 'master' title with authority and control, not realising Scrum explicitly rejects command-and-control management.
Mistake
The Daily Scrum is a status meeting where each person reports progress to the manager.
Correct
The Daily Scrum is a planning meeting for the Development Team to inspect progress toward the Sprint Goal and adapt their plan for the next 24 hours.
In traditional workplaces, daily stand-ups are often used as micromanagement tools, so beginners assume that's what Scrum intends.
Mistake
The Product Owner can delegate their responsibility to a committee or multiple people.
Correct
The Product Owner is a single person who owns the Product Backlog and is ultimately accountable for its content and ordering.
Many organisations try to spread the role across a 'product committee', which violates the Scrum principle of single-window accountability.
Mistake
Artifacts like the Product Backlog are created once and never change during the project.
Correct
The Product Backlog is a living artifact that is continuously refined and re-ordered based on feedback, new requirements, and changing priorities.
Beginners mistake the name 'backlog' as a fixed requirements document, similar to a traditional scope statement.
Mistake
The Sprint Review and the Sprint Retrospective are the same meeting.
Correct
The Sprint Review inspects the product and adapts the Product Backlog. The Sprint Retrospective inspects the process and adapts how the team works.
Both happen at the end of the Sprint and sound similar, so beginners conflate them without understanding their distinct focus.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Sprint Review is about the product: you inspect the working Increment and adapt the Product Backlog. The Sprint Retrospective is about the process: you inspect how the team worked and decide how to improve.
The Product Owner is the single person accountable for managing the Product Backlog, including its content, ordering, and transparency.
No. The Daily Scrum is a real-time, 15-minute event where the Development Team inspects progress and adapts their plan. It is not a status update and cannot be replaced by asynchronous communication.
No. A Scrum Master is a servant-leader who coaches the team on Scrum, removes obstacles, and helps the team be self-organising. A project manager in a traditional sense would assign tasks and control the plan, which is not allowed in Scrum.
The Definition of Done is a checklist created by the Development Team that states what must be true for a Product Backlog item to be considered complete. It ensures every Increment is truly 'done' and potentially releasable.
No. The Scrum team consists only of the Product Owner, the Development Team, and the Scrum Master. Stakeholders are external people who provide input during Sprint Reviews and other interactions.
You've finished Agile Roles, Events, and Artifacts. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?