Core Concepts
Agile Manifesto: The Philosophy Behind the Process
The Agile Manifesto (2001) is the philosophical foundation of everything in this module. Its four values and twelve principles define Agile as a mindset first, a process second. Without understanding the Manifesto, Scrum and Kanban look like arbitrary ceremonies. With it, every ceremony has a reason to exist and a way to be evaluated.
The Four Values and What They Mean for PMs
What It Means
No process, however well-designed, replaces a high-trust team with direct communication. Processes serve teams, teams do not serve processes.
PM Behaviour
When a ceremony adds no value, challenge it. Talk directly to engineers instead of routing everything through tickets. Optimise for team clarity over process compliance.
What It Means
A working increment demonstrated to stakeholders is worth more than a perfectly written PRD that describes something nobody has built. Documentation should serve the work, not replace it.
PM Behaviour
Write just enough specification to enable building. Use Sprint Reviews to demonstrate working software to stakeholders rather than presenting status slides. Ship first, document what matters.
What It Means
Involving customers throughout development produces better outcomes than locking requirements upfront and defending them. Requirements will change, the question is whether you change them with or without the customer.
PM Behaviour
Talk to users every sprint, not once at the start. Bring real user feedback into Sprint Reviews. Treat the backlog as a living document shaped by continuous customer input, not a contract signed once.
What It Means
Markets shift. User needs evolve, and technology changes. An Agile PM builds a process that adapts to these changes rather than a plan that predicts and resists them.
PM Behaviour
Treat your roadmap as a direction, not a commitment. Adapt sprint priorities when new evidence arrives. Protect the team from arbitrary scope changes while remaining genuinely responsive to impact and learning.
Important Clarification
The Manifesto does not say processes, documentation, contracts, or plans have no value. It says the items on the left are valued more. A team that produces no documentation and ignores its roadmap is not being Agile, it is being undisciplined. The values define priorities, not absolutes.
Agile vs Waterfall: Understanding What Changed and Why
Many learners come from Waterfall environments. Without a comparison, Agile looks like chaos. The contrast shows why Agile was created, not to replace rigor, but to replace rigidity. Waterfall excels when requirements are fully known upfront. Agile excels when requirements will change, which is most of the time in modern product work.
Agile was created as a response to Waterfall's limitations in environments where requirements change. Understanding the contrast clarifies what Agile changes and what it does not.
| Dimension | Waterfall | Agile |
|---|---|---|
| Planning style | Comprehensive upfront planning. All requirements defined before development begins. | Just-in-time planning. High-level direction set upfront; details refined sprint by sprint. |
| Delivery cadence | Single delivery at project end, often months or years after development begins. | Working increment every sprint (1–4 weeks). Value delivered continuously. |
| Feedback frequency | Feedback gathered after delivery. Changes are expensive and often rejected. | Feedback gathered every sprint via Sprint Review. Changes incorporated in the next sprint. |
| Documentation | Comprehensive PRDs, functional specs, and design documents required before building. | Lightweight specifications. User stories and acceptance criteria. PRDs written progressively for large features only. |
| Change tolerance | Change is controlled and resisted. Change requests go through a formal process. | Change is expected and welcomed when based on evidence. Backlog can be re-ordered between any two sprints. |
| Risk profile | Risk is front-loaded. Problems are discovered late when cost to fix is highest. | Risk is distributed. Each sprint surfaces issues early when the cost to address them is lowest. |
| When it fits best | Requirements are fully known and stable: construction, manufacturing, regulated industries with fixed specs. | Requirements will evolve: software, product development, and any domain where user feedback improves the outcome. |
What Agile did not eliminate
Agile replaced monolithic upfront PRDs with lightweight, just-in-time specifications. PMs in mature Agile teams still write product briefs for large features and epics, but detail is added progressively rather than front-loaded. Documentation evolved; it did not disappear.
Scrum: The Most Widely Used Agile Framework
Scrum is a lightweight framework for managing complex work in short cycles. It has three roles, five events, and three artifacts, all precisely defined in the Scrum Guide. PMs typically operate as the Product Owner in Scrum, owning the "what" and the "why" while the Scrum Master owns the "how" and the process. Understanding the boundary between these roles is essential.
Product Owner
Owns the what and the why
The Product Owner is accountable for the value of the product. They own the Product Backlog: ordering it, refining it, and explaining the goal behind every item. The PM often holds this role, but not always.
PM boundary
The PO defines what gets built and why. The team decides how. The Developer builds it. Technical decisions belong to the Developers.
Scrum Master
Owns the how and the process
The Scrum Master is accountable for Scrum being understood and enacted. They facilitate ceremonies, remove impediments, and coach the team on Scrum practices. They do not manage the team.
Common PM mistake
PMs who act as the Scrum Master while also facilitating retrospectives, resolving team conflicts, or managing ceremony agendas remove the Scrum Master's purpose and create role confusion that damages team health.
Developers
Build the product increment
The people who do the work of creating a usable increment each sprint. The Scrum Guide (2020) uses "Developers" not "Development Team" or "Team". This applies to roles with all skills needed to build the increment though those performing design, QA, and others.
Useful terminology
"Development Team" was the term used before the 2020 Scrum Guide update. "Developers" is the current correct term for certification-level accuracy.
PM vs Scrum Master
Where the boundary sits
Two PMs frequently confuse these roles or step into each other's responsibilities. The boundary is not arbitrary. It protects both team autonomy and product clarity.
PM / Product Owner
Owns the what and why. Sprint Goals, backlog clarity, value tracking, and stakeholder communication.
Scrum Master
Owns the how and process. Ceremony facilitation, impediment removal, and coaching Scrum health.
The Sprint: The container for all other events
A time-boxed event of one to four weeks in which the team creates a usable increment. No goals are changed that would endanger the Sprint Goal. Quality standards do not decrease.
Sprint Planning: Selecting what the sprint will achieve
The team selects items from the Product Backlog and commits to a Sprint Goal. The PM (as Product Owner) brings a prioritized backlog and presents the Sprint Goal.
Daily Scrum: 15-minute sync for Developers
A daily event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The PM typically attends but does not lead.
Sprint Review: Demonstrating the increment to stakeholders
The team demonstrates the working increment to stakeholders and collects feedback. The PM facilitates the session and translates stakeholder input into backlog updates.
Sprint Retrospective: The team reflects on process
The team inspects how the last Sprint went and identifies improvements. Output: at least one actionable improvement committed for the next sprint.
Kanban: Flow-Based Work Management
Kanban is not Scrum with a board. It is a fundamentally different approach. Continuous flow instead of fixed sprints, WIP limits instead of sprint commitments, and flow metrics instead of velocity. Choosing between Scrum and Kanban is one of the most common decisions PMs face when joining or forming a team. The choice should be driven by the nature of the work, not team preference.
WIP Limits
The core Kanban mechanism
Work in Progress limits cap the number of items that can be in any one column at the same time. When a column is full, no new work enters until an item exits. WIP limits make bottlenecks visible and force teams to finish work rather than start new work.
PM Responsibility
Set WIP limits collaboratively with the team. Challenge teams that consistently hit their limits, as it is a signal of a bottleneck that needs to be resolved, not a limit that needs to be raised.
Kanban Board Columns
Visualising the flow of work
A Kanban board maps the actual steps work moves through. Typical columns: Backlog → Ready → In Progress → Review → Done. Each column reflects a real workflow stage. Boards should be designed around how the team actually works, not how a template suggests.
PM Responsibility
Ensure the board reflects reality. A card that sits in "In Progress" for three weeks is not in progress, it is blocked. Make blocking visible and resolve it rather than leaving it in an active column.
Cycle Time
How long work takes to complete
Cycle time measures the time from when work starts (first moved to In Progress) to when it is done. It is the primary flow metric for Kanban teams. Shorter, more consistent cycle times mean more predictable delivery.
PM Focus
Track the median and 85th percentile cycle time, not just the average. High variability in cycle time signals inconsistent work item sizing. Break large items into smaller, more predictable chunks.
Lead Time vs Throughput
Two views of flow health
Lead time is the total elapsed time from when work is requested to when it is delivered, including wait time before work starts. Throughput is the number of items completed per unit of time. Both matter: cycle time measures process efficiency; lead time measures delivery from the customer's perspective.
PM Usage
Use lead time for stakeholder commitments ("expect this in about two weeks"). Use throughput to forecast how many items your team can deliver in a quarter. Use cycle time to diagnose process bottlenecks.
This is one of the most common questions PMs face when joining or forming a team. The choice should be driven by the nature of the work.
| Dimension | Choose Scrum when… | Choose Kanban when… |
|---|---|---|
| Work nature | Work arrives in predictable batches that can be planned sprint by sprint. | Work is continuous, unpredictable, or support-oriented with varied item sizes. |
| Feedback loops | Regular stakeholder demos and retrospectives are needed to steer direction. | Continuous delivery with immediate feedback is more important than sprint-level checkpoints. |
| Team structure | A stable, cross-functional team building a product through defined iterations. | Operations, support, maintenance, or shared service teams handling inbound requests. |
| PM need | PM wants to define sprint scope and set a Sprint Goal each cycle. | PM wants to prioritise a continuous queue and optimise for flow speed. |
Agile Estimation: Sizing Work Without Faking Precision
Agile estimation deliberately avoids time-based estimates because time estimates feel precise but are unreliable for complex work. Story points, T-shirt sizing, and Planning Poker replace false precision with calibrated relative sizing. A PM who cannot facilitate estimation cannot run Sprint Planning or Backlog Refinement effectively.
Story points estimate relative effort and complexity compared to other items, not actual time. A 5-point story is roughly five times as complex as a 1-point story for this team, at this time, with current knowledge. Story points are calibrated within a team and never comparable across teams.
Why not hours?
Hours imply a precision that does not exist for complex work. This creates false different predictions across the team. Story points deliberately avoid false precision while still enabling relative comparisons and velocity tracking.
T-shirt sizing (XS, S, M, L, XL) is a fast estimation method used for features or epics that are too large or too vague for story-point estimation. Used in roadmap planning when precision is less important than directional sizing for prioritisation.
When to use
Use T-shirt sizing early in discovery when estimating epics for roadmap sequencing. Switch to story points when work is broken into user stories ready for a sprint backlog.
Each team member privately selects a card representing their estimate. Cards are revealed simultaneously. Significant divergence triggers discussion, the most valuable part of the process. Consensus is reached after discussion, not averaging.
PM facilitation
When estimates diverge, the highest and lowest estimators explain their reasoning first. This goal is shared understanding of complexity, not mathematical agreement. Discussion often reveals hidden risks or assumptions the team had not aligned on.
Effort is how much work a task requires. Time is when it will be done. A 5-point story takes less effort than a 13-point story, but both could take a similar number of calendar days depending on team availability, dependencies, and interruptions.
PM mistake to avoid
Converting story points directly to hours or days in stakeholder conversations destroys the value of relative estimation. Quote delivery ranges using velocity and sprint count, not a story-point-to-hour conversion that implies false accuracy.