Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Agile
Small steps, constant feedback
Imagine renovating a house one room at a time. You finish the kitchen, live with it for a couple of weeks, and then decide what the bathroom needs based on what you’ve learned. You never end up with a whole house that’s wrong.
That’s agile. Instead of one big delivery at the end, the team delivers working software in short cycles called sprints (usually two to four weeks), and users steer what gets built next.
The Agile Manifesto values individuals and interactions, working software, customer collaboration and responding to change. It doesn’t throw away processes, documentation, contracts or plans; it just values the first set more.
| Waterfall | Agile | |
|---|---|---|
| Requirements | Fixed early | Evolve in a prioritised backlog |
| Delivery | One release at the end | A working piece every sprint |
| User involvement | Mainly at the start and end | Continuous, through the product owner |
| Documentation | Extensive | Just enough |
| Change | Costly and formal | Expected, managed in the backlog |
Scrum: the most common agile method
Roles
| Role | What they do |
|---|---|
| Product owner | Represents the business; owns and orders the product backlog; accepts finished work |
| Scrum master | Coaches the team in Scrum and removes blockers; not a traditional manager |
| Development team | Cross-functional and self-organising; designs, builds and tests |
Artefacts
- Product backlog: the ordered to-do list for the whole product.
- Sprint backlog: the items picked for this sprint.
- Increment: the working software produced.
Events
The sprint review shows the product to stakeholders. The retrospective is about improving how the team works. The exam likes to mix them up.
Other agile approaches include Kanban (visualise the work on a board and limit how much is in progress), Extreme Programming (pair programming, test-driven development) and scaled frameworks such as SAFe.
Where controls slip
Agile isn’t “no controls”. It’s “just enough, at the right time”. The risks come from time pressure and lighter documentation:
| Risk | Why it happens | What good looks like |
|---|---|---|
| Security and controls skipped | Pressure to hit sprint goals | Security requirements in the backlog; definition of done includes security testing and review |
| Not enough audit evidence | Less formal documentation | Backlog, ticket history, automated test results, pipeline logs |
| Weak change control | Frequent releases | Automated pipelines that enforce review, testing and approval |
| Technical debt and architecture drift | Focus on short-term delivery | Architecture guidance; debt tracked in the backlog |
| Unclear accountability | Self-organising teams | Product owner accountable for acceptance; clear release approval |
The definition of done
The definition of done is the checklist every story must meet before it counts as finished. It’s the most powerful control in agile: put security and testing in it, and they can’t be skipped.
Example. A team’s definition of done says “code merged and demoed”. Security scanning is a separate task that keeps getting pushed to the next sprint. The auditor recommends adding passing security scans and peer review to the definition of done, so a story can’t be closed without them.
The auditor in agile
- Get involved early and regularly, for example by attending sprint reviews.
- Check the backlog and definition of done for control and security requirements.
- Use automated evidence: version control history, pipeline approvals, test results.
- Review controls per release rather than per traditional phase.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who prioritises the backlog | Product owner |
| The role that removes impediments | Scrum master |
| Biggest control concern in agile | Controls and documentation reduced or skipped under time pressure |
| How to embed security in agile | User stories, acceptance criteria and the definition of done |
| The event that demonstrates work to stakeholders | Sprint review |
In short
- Agile delivers working software in short iterations (sprints), with continuous user involvement and adaptation to change.
- Scrum roles: product owner (prioritises the backlog, represents the business), scrum master (facilitates, removes obstacles), development team (builds).
- Scrum events: sprint planning, daily stand-up, sprint review (demo to stakeholders), sprint retrospective (process improvement).
- Documentation is lighter, but controls still need evidence: acceptance criteria, definition of done, approvals, test results.
- Security and control requirements belong in the backlog and the definition of done.
- The auditor adapts by reviewing controls per sprint or release and relying more on automated evidence.
Exam traps
- Agile doesn't mean no documentation or no controls; it means just enough, at the right time.
- The product owner accepts work for the business; the scrum master isn't a project manager with authority over the team.
- Without a definition of done that includes security and testing, controls can be skipped to finish sprints.
- Frequent releases still go through change management, often automated.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Who's who in Scrum
One sprint
The definition of done