7.5 Agile Project Controls and Artifacts

CAPM Certified Associate in Project Management Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CAPM Exam Overview

1.1 About the CAPM Exam 1.2 PMBOK 7th Edition Overview 1.3 Exam Content Outline (ECO) 1.4 CAPM vs. PMP: Understanding the Differences

2 Chapter 2: Project Life Cycles and Processes (Domain 1, Tasks 1-2)

2.1 Projects, Programs, and Portfolios 2.2 Project Life Cycle Phases 2.3 The Five Process Groups 2.4 The Ten Knowledge Areas

3 Chapter 3: Project Management Planning (Domain 1, Task 2)

3.1 The Project Management Plan 3.2 Scope Management and the WBS 3.3 Schedule Management 3.4 Cost Management and Earned Value 3.5 Quality Management

4 Chapter 4: Project Roles, Responsibilities, and Ethics (Domain 1, Tasks 3-4)

4.1 Project Roles and Responsibilities 4.2 Leadership and Emotional Intelligence 4.3 Risk Management Fundamentals 4.4 PMI Code of Ethics and Professional Conduct 4.5 Problem-Solving Tools and Techniques

5 Chapter 5: Resource, Communication, and Stakeholder Management (Domain 1, Tasks 2-3)

5.1 Resource Management 5.2 Communications Management 5.3 Stakeholder Management 5.4 Procurement Management 5.5 Issues, Risks, Assumptions, and Constraints

6 Chapter 6: Predictive, Plan-Based Methodologies (Domain 2)

6.1 When to Use a Predictive Approach 6.2 WBS, Work Packages, and Activity Definition 6.3 Predictive Project Controls and Artifacts 6.4 Critical Path and Schedule Calculations

7 Chapter 7: Agile Frameworks and Methodologies (Domain 3, Tasks 1-3)

7.1 When to Use an Adaptive (Agile) Approach 7.2 The Scrum Framework 7.3 Kanban, XP, and SAFe 7.4 Agile Planning, Estimation, and Metrics 7.5 Agile Project Controls and Artifacts

8 Chapter 8: Business Analysis Roles and Stakeholder Communication (Domain 4, Tasks 1-2)

8.1 Business Analysis Roles and Responsibilities 8.2 Stakeholder Communication in Business Analysis 8.3 Business Case and Needs Assessment

9 Chapter 9: Requirements Gathering and Product Roadmaps (Domain 4, Tasks 3-4)

9.1 Requirements Gathering Approaches 9.2 Requirements Traceability Matrix 9.3 Product Roadmaps

10 Chapter 10: BA Methodologies and Requirements Validation (Domain 4, Tasks 5-6)

10.1 Business Analysis in Predictive and Agile Approaches 10.2 Acceptance Criteria and Requirements Validation 10.3 Business Analysis Tools and Techniques Summary

7.5 Agile Project Controls and Artifacts

Key Takeaways Explain This Topic AI

Agile control comes from transparency and frequent inspection (information radiators, events) rather than formal change control boards

Prioritization techniques: MoSCoW (Must/Should/Could/Won't-have), value-vs-effort matrix, and Weighted Shortest Job First (WSJF = Cost of Delay / Job Size)

Definition of Done is a team-wide quality standard for every increment; acceptance criteria are story-specific conditions set with the Product Owner

Agile-friendly contracts (Time and Materials, fixed-price-per-Sprint, Money for Nothing/Change for Free) replace rigid fixed-scope contracts

The Sprint Retrospective is the primary continuous-improvement mechanism; formats include Start-Stop-Continue, Mad-Sad-Glad, 4Ls, and Sailboat

Last updated: June 2026

How Agile Controls Work

Predictive projects control change through a change control board (CCB) and formal change requests. Agile projects achieve control differently — through transparency, frequent inspection, and continuous adaptation . Change is not gated; it is welcomed into the Product Backlog and reprioritized. The exam reward is recognizing that an agile answer rarely says "submit a change request to the CCB" — it says "add it to the backlog and let the Product Owner prioritize."

Information Radiators

Information radiators are highly visible, low-effort displays that broadcast status so the team reduces meetings and reports:

Radiator Purpose
Task/Kanban Board Status of every work item by stage
Burndown Chart Remaining work in the current Sprint
Burnup Chart Completed work against total scope
Velocity Chart Velocity trend across Sprints
Cumulative Flow Diagram WIP and flow across all stages
Impediment Board Active blockers and their owners

Principle: Radiators embody transparency . If a question contrasts "detailed weekly status report to executives" with "a visible team board," the agile-preferred answer is the radiator.

Backlog Prioritization
MoSCoW

Category Meaning
Must have Non-negotiable; release fails without it
Should have Important; a workaround exists
Could have Desirable; nice to have
Won't have (this time) Explicitly deferred this release

The second "o" in MoSCoW is just filler; the real categories are M, S, C, W . The exam often tests that W = Won't have this time (deferred, not deleted forever).

Value vs. Effort matrix

Low Effort High Effort
High Value Quick wins — do first Big bets — plan carefully
Low Value Fill-ins — when convenient Avoid — not worth it
Weighted Shortest Job First (WSJF)

SAFe's economic prioritization: WSJF = Cost of Delay ÷ Job Size (duration) , where Cost of Delay = User/Business Value + Time Criticality + Risk Reduction/Opportunity Enablement . The highest WSJF goes first , which mathematically favors short, high-value jobs.

Definition of Done vs. Acceptance Criteria

These are frequently confused — and frequently tested.

Definition of Done (DoD) Acceptance Criteria
Scope Team-wide; every story/Increment One specific story
Created by The Scrum Team Product Owner (with team)
Question it answers "Is it built to our quality bar?" "Does this story do what was asked?"

Example DoD: code peer-reviewed; unit and integration tests pass; coding standards met; documentation updated; no critical defects. Example acceptance criteria (often Given/When/Then): Given a valid cart, when the user clicks checkout, then they reach the payment page; given invalid payment data, when submitted, then an error displays. A story must satisfy both its acceptance criteria and the DoD before it is Done.

Agile Contracting

Fixed-scope, fixed-price contracts fight agile's welcome-change stance, so agile-friendly arrangements share risk:

Approach How it works
Time and Materials (T&M) Pay for time/effort; scope stays flexible
Fixed price per Sprint/iteration Fixed cost per Sprint; scope negotiated each Sprint
Graduated / incentive Bonuses or penalties tied to delivery

Money for Nothing, Change for Free Customer may end early and keep unused budget; in-budget scope swaps are free

Continuous Improvement

The Sprint Retrospective is the engine of improvement, but learning also flows from Daily Scrums (impediments), Sprint Reviews (product feedback), metrics analysis (velocity, cycle time, defects), root-cause analysis, and Lean Kaizen events. Improvement items often become Sprint Backlog work so they are actually done.

Retrospective formats

Format How it works
Start, Stop, Continue What to begin, end, and keep doing
Mad, Sad, Glad Surface emotions about the Sprint
4Ls Liked, Learned, Lacked, Longed for
Sailboat Wind (helps), Anchors (slows), Rocks (risks), Island (goal)

Rotating formats keeps retrospectives fresh and combats "retro fatigue," but the output is always the same : a small number of concrete, owned improvement actions the team commits to next Sprint.

Control Through Transparency, Not Gatekeeping

The deepest CAPM theme in this section is that agile control is built in , not bolted on. Because the Increment is inspected every Sprint Review, defects and misalignment surface within weeks rather than at a final gate. Because the board and burndown radiate status continuously, a slipping Sprint is visible the same day, not in next month's report. Because the backlog is reprioritized every Sprint, the project stays aimed at the highest-value work as the world changes.

This is why an agile-correct answer to "how do we keep this project under control" emphasizes frequent inspection points, visible information, and empowered reprioritization — not a heavyweight approval chain. The Product Owner controls what is built (value and order); the Developers control how (technical decisions and the Sprint plan); the Definition of Done controls the quality bar . Separating those three loci of control is a frequent exam distinction.

Acceptance, Done, and Release — A Worked Example

Suppose a story reads, "As a shopper, I want to apply a promo code at checkout so that I get my discount." Its acceptance criteria might be: a valid code reduces the total correctly; an expired code shows a clear error; a blank code leaves the total unchanged. The team's Definition of Done then layers on universal quality: peer-reviewed code, passing unit and integration tests, updated documentation, and no critical defects. The story is only Done when it satisfies both — its specific acceptance criteria and the team-wide Definition of Done.

Even then, release timing is the Product Owner's call, since meeting the Definition of Done makes an Increment usable but not automatically deployed . Keeping acceptance criteria, Definition of Done, and the release decision distinct is exactly the kind of layered control CAPM rewards.