7.5 Agile Project Controls and Artifacts
Key Takeaways
- Agile project controls rely on transparency through information radiators, regular ceremonies, and continuous feedback rather than formal change control
- Key agile artifacts include the product backlog, sprint backlog, increment, definition of done, burndown/burnup charts, and task boards
- Prioritization techniques include MoSCoW (Must, Should, Could, Won t), value vs. effort matrices, and weighted shortest job first (WSJF)
- Agile teams use retrospectives as the primary mechanism for continuous improvement and process adaptation
- The product backlog is a living artifact that is continuously refined, reprioritized, and updated as the team learns more
Agile Project Controls and Artifacts
Unlike predictive projects that use formal change control, agile projects rely on transparency, frequent inspection, and continuous adaptation to maintain control. This section covers agile artifacts and control mechanisms.
Information Radiators
Information radiators are highly visible displays of project information placed where the team (and stakeholders) can see them at all times:
| Radiator | Purpose |
|---|---|
| Task/Kanban Board | Shows the status of all work items across workflow stages |
| Burndown Chart | Displays remaining work in the current Sprint |
| Burnup Chart | Shows completed work against total scope |
| Velocity Chart | Tracks velocity trends over multiple Sprints |
| Cumulative Flow Diagram | Visualizes WIP and flow across all stages |
| Impediment Board | Lists current blockers and their status |
Key Principle: Information radiators embody the agile principle of transparency. They make project status visible at a glance, eliminating the need for frequent status reports and meetings.
Product Backlog Management
The Product Backlog is the single source of truth for all work to be done on the product. It is owned and prioritized by the Product Owner.
Backlog Prioritization Techniques
MoSCoW Method
| Category | Description | Commitment |
|---|---|---|
| Must Have | Critical requirements that must be delivered | Non-negotiable |
| Should Have | Important but not vital; workarounds exist | High priority |
| Could Have | Desirable but not necessary; nice to have | Lower priority |
| Won't Have (this time) | Acknowledged but explicitly excluded from current scope | Deferred |
Value vs. Effort Matrix
Plot backlog items on a 2x2 grid:
| Low Effort | High Effort | |
|---|---|---|
| High Value | Quick Wins — Do first | Major Projects — Plan carefully |
| Low Value | Fill-ins — Do when convenient | Avoid — Not worth the investment |
Weighted Shortest Job First (WSJF)
Used in SAFe to prioritize based on cost of delay:
WSJF = Cost of Delay / Job Duration
Where Cost of Delay = User/Business Value + Time Criticality + Risk Reduction/Opportunity Enablement
Higher WSJF scores = higher priority
Definition of Done vs. Acceptance Criteria
| Concept | Scope | Created By | Applied To |
|---|---|---|---|
| Definition of Done (DoD) | Team-wide quality standard | The Scrum Team | Every user story and increment |
| Acceptance Criteria | Story-specific conditions | Product Owner | Individual user stories |
Example Definition of Done
- Code is peer-reviewed
- All unit tests pass
- Integration tests pass
- Code meets coding standards
- Documentation is updated
- No critical defects remain
- Product Owner has approved the feature
Example Acceptance Criteria (for a specific story)
- Given a customer with items in cart, when they click checkout, then they are redirected to payment
- Given invalid payment information, when submitted, then an error message displays
- Given successful payment, when confirmed, then an order confirmation email is sent
Agile Contracting
Traditional fixed-scope contracts do not align well with agile principles. Agile-friendly contract approaches include:
| Approach | Description |
|---|---|
| Time and Materials (T&M) | Pay for time worked; flexible scope |
| Fixed price per Sprint | Pay a set amount per Sprint; negotiate scope each Sprint |
| Target Cost/Target Scope | Shared risk with incentives for delivering within targets |
| Money for Nothing, Change for Free | Early termination clause gives unused budget back; scope changes within budget are free |
Continuous Improvement
The primary mechanism for continuous improvement in agile is the Sprint Retrospective, but improvement also comes from:
- Daily Scrums — Identify and address impediments daily
- Sprint Reviews — Gather stakeholder feedback for product improvement
- Metrics analysis — Use velocity, cycle time, and defect trends to identify patterns
- Root cause analysis — Investigate systemic issues
- Kaizen events — Focused improvement workshops (from Lean)
Retrospective Formats
| Format | How It Works |
|---|---|
| Start, Stop, Continue | What should the team start doing, stop doing, and continue doing? |
| Mad, Sad, Glad | What made the team frustrated, disappointed, or happy? |
| 4Ls | What did the team Like, Learn, Lack, and Long for? |
| Sailboat | Wind (what helps), Anchors (what slows), Rocks (risks), Island (goal) |
In the MoSCoW prioritization method, what does the "S" stand for?
What is the difference between the Definition of Done and Acceptance Criteria?
Information radiators in agile projects are used primarily to: