7.5 Agile Project Controls and Artifacts

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:

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

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

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.

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:

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

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.