Everything in PM4000 through PM4070 assumes scope can be defined upfront and locked down through change control. PM4080 challenges that assumption: for many modern projects — especially software — requirements are genuinely unknowable in full at the start, and Agile exists to manage that reality productively instead of fighting it.
The Agile Manifesto and Scrum framework
PM4080 begins with the four values and twelve principles of the 2001 Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The course then teaches Scrum as the most widely used Agile framework: the three roles (Product Owner, Scrum Master, Development Team), the five events (sprint, sprint planning, daily scrum, sprint review, sprint retrospective), and the three artifacts (product backlog, sprint backlog, increment).
Kanban and choosing Agile vs. Waterfall
Kanban is introduced as a lighter-weight alternative to Scrum, using a visual board with work-in-progress (WIP) limits to manage continuous flow rather than fixed-length sprints — well suited to support and maintenance work where tasks arrive unpredictably. The course closes by teaching students to evaluate project characteristics (requirements stability, customer availability, team co-location, regulatory constraints) to choose between Agile, Waterfall, or a hybrid approach, rather than treating Agile as automatically superior.
Key topics in PM4080
- The Agile Manifesto: four values and twelve principles
- Scrum roles: Product Owner, Scrum Master, Development Team
- Scrum events: sprint, sprint planning, daily scrum, sprint review, sprint retrospective
- Scrum artifacts: product backlog, sprint backlog, product increment, and the definition of done
- User stories and story points: writing and estimating backlog items
- Kanban: visual boards, WIP limits, and continuous flow vs. sprint-based delivery
- Choosing Agile, Waterfall, or a hybrid approach based on project characteristics
Working on a Scrum framework analysis or an Agile-vs-Waterfall comparison?
Our project management experts build PM4080-level coursework with accurate Scrum and Kanban frameworks.
Worked example: a two-week Scrum sprint cycle
- Sprint planning (day 1): Team selects top-priority items from the product backlog, committing to a sprint backlog and a sprint goal
- Daily scrum (days 2-9): 15-minute daily stand-up — what was done, what's next, any blockers — no problem-solving in the meeting itself
- Development (ongoing): Team builds a working, potentially shippable increment by the end of the sprint
- Sprint review (day 10): Team demonstrates the increment to the Product Owner and stakeholders, gathering feedback
- Sprint retrospective (day 10): Team reflects on what went well and what to improve in the next sprint's process
Get Help With PM4080
Scrum framework papers, Agile-vs-Waterfall analyses, sprint-planning case studies.
Place Your OrderView All ServicesRelated courses
Frequently asked questions
A Scrum Master is a servant-leader role focused on facilitating the Scrum process and removing obstacles for the Development Team — they do not assign tasks, direct the team's work, or manage scope, schedule, and budget the way a traditional project manager does. Decisions about what to build and in what order belong to the Product Owner, and decisions about how to build it belong to the self-organizing Development Team; the Scrum Master's job is to ensure the Scrum framework (events, artifacts, roles) is understood and followed, coach the team toward higher performance, and shield them from external interruptions during a sprint. PM4080 teaches this distinction because it's a common misconception among students familiar with traditional PM roles: the Scrum Master has influence and facilitation authority, but explicitly not the command-and-control authority a traditional project manager holds over scope, schedule, and resource assignment.
Agile tends to fit better when requirements are expected to evolve, the customer or product owner can be closely involved throughout the project (not just at the start and end), and the work can be delivered in small, independently valuable increments — software development is the classic example, since user needs often only become clear after seeing a working version. Waterfall tends to fit better when requirements are well understood and unlikely to change, the cost of changing course later is very high (e.g., construction, hardware manufacturing, or regulated industries with fixed compliance requirements), and stakeholders need a fixed, detailed plan upfront for budgeting or contractual reasons. PM4080 teaches that the choice isn't ideological — it's a matter of matching the delivery approach to how much the project's requirements are likely to change and how much iterative feedback is actually possible to obtain during execution.