Agile, Scrum & Hybrid

A sprint is a fixed-length iteration, typically one to four weeks, during which a Scrum team plans, develops, and delivers a potentially shippable product increment. Its duration is set once and held constant so the team builds a predictable cadence, enabling reliable velocity measurement and stakeholder forecasting. On PMP questions, separate a sprint from a release: a sprint yields a potentially shippable increment, but the product owner decides whether it ships. Sprints never overlap and are not extended for incomplete scope; unfinished work returns to the product backlog for re-prioritization, not automatic carry-over.

The product backlog is a prioritized, ordered list of all features, fixes, and improvements that may be needed in a product, owned and managed by the product owner. It is a living artifact that evolves as stakeholders refine requirements and team capacity becomes clearer. Backlog refinement keeps top items detailed enough for the next sprint, while lower-priority items stay broad. On the PMP exam, distinguish it from the sprint backlog: the product backlog holds everything the product might need, while the sprint backlog holds only the subset the team commits to in a single sprint. The product owner controls the product backlog; the developers own the sprint backlog.

Velocity measures how much work an agile team completes per iteration, expressed in story points or accepted stories. Teams sum the points of stories fully accepted at the sprint review and average several sprints to get a stable planning figure, then use it to forecast remaining sprints and the release date. The exam distinction: velocity is effort-weighted, while throughput counts items regardless of size. Velocity is team-specific and a lagging indicator, so never use it to rank teams, and expect new teams to need a few sprints before it stabilizes.

A burndown chart plots remaining work (story points or tasks) on the vertical axis against time on the horizontal, so the team sees whether it will finish committed work before the sprint or iteration ends. An ideal line descends diagonally from total planned work to zero, and the actual line is compared against it. The critical exam distinction is burndown versus burnup: a burndown tracks what is left to do, while a burnup tracks completed work building toward a fixed scope line, making scope changes immediately visible. On predictive projects, an S-curve or schedule performance index (SPI) serves a similar role.

Kanban is a pull-based agile method that visualizes work on a board of columns representing workflow states, with team members pulling new items only when capacity exists. Its defining mechanism is the Work In Progress (WIP) limit per column, which reduces multitasking, exposes bottlenecks, and improves flow efficiency. Unlike Scrum, Kanban uses no fixed-length iterations or prescribed roles, suiting continuous-delivery environments where work arrives unpredictably. On the PMP exam, contrast the two: Scrum manages flow with sprints and velocity, while Kanban manages it with WIP limits and cycle time within an adaptive or hybrid approach.

A Minimum Viable Product (MVP) is the earliest deployable increment containing only the features needed to satisfy initial adopters and generate validated learning about customer needs. In agile and hybrid delivery, it is a deliberate risk-reduction move: releasing the smallest functional slice tests core assumptions before committing further budget and schedule. On the exam, distinguish an MVP from a prototype—a prototype is a disposable, often non-functional demonstration used to visualize a concept, whereas an MVP is a real working product released to real users. MVPs deliver incremental business value and inform backlog refinement.

The Definition of Done (DoD) is a team-agreed checklist specifying every condition a deliverable must satisfy before it can be declared complete — covering items such as unit testing, integration testing, peer review, documentation, and acceptance sign-off. In agile and hybrid projects, the DoD applies uniformly to every increment, preventing teams from carrying hidden “almost done” work into future iterations. The critical exam distinction is between the DoD and acceptance criteria: acceptance criteria are specific to an individual user story or deliverable, while the DoD is a blanket quality standard applied to all work items. Meeting acceptance criteria alone does not satisfy the DoD if broader quality gates remain open.

Agile is an adaptive delivery approach grounded in the four values and twelve principles of the Agile Manifesto. Teams deliver value in short iterations, allowing requirements to evolve through continuous stakeholder feedback rather than being locked in upfront. This suits projects with high uncertainty where scope cannot be fully defined at the start. On the PMP exam, the critical distinction is between agile and predictive: the trigger for choosing agile is uncertainty and the need for flexibility, not project size or speed. Selecting agile simply because a project is “small” or “fast-moving” is a common distractor.

A hybrid approach blends predictive (waterfall) and agile methods within one project, applying each where it delivers the most value. Stable, well-understood deliverables follow a planned, sequential lifecycle, while uncertain or rapidly changing components use iterative sprints. PMI’s Examination Content Outline places roughly half of exam questions in agile or hybrid contexts, so knowing when and why to blend methods is central. Hybrid is not a compromise—it is a deliberate choice driven by the complexity and uncertainty profile of each work stream, traced to the project’s tailoring decisions recorded in the development approach section of the project management plan.

The predictive approach, often called waterfall, organizes work into sequential life-cycle phases where each phase produces deliverables that feed the next. Scope, schedule, and cost baselines are defined early and governed through formal integrated change control, so any deviation must go through an approved change request before work adjusts. Note that initiating, planning, executing, monitoring and controlling, and closing are the five process groups that recur within phases, not a strict linear sequence—monitoring and controlling runs continuously. The exam trigger for choosing predictive is low uncertainty with stable, fully definable requirements up front; adaptive (agile) methods suit high-uncertainty, evolving-scope work.

The Scrum Master is a servant leader who helps a Scrum team perform at its best by facilitating the five Scrum events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint itself), coaching members on the framework, and removing impediments that block progress. The role protects the team’s focus and upholds Scrum values rather than directing the work. On the PMP exam, the key distinction from a traditional project manager is authority: the Scrum Master cannot assign tasks, set backlog priority, or make business decisions—those belong to the Product Owner. Their influence is facilitative and coaching-based.

In Scrum and hybrid environments, the Product Owner is the single person accountable for maximizing the value the team delivers. This role owns the product backlog — defining, ordering, and communicating its items — and is the final authority on accepting completed work. The PMP exam often tests the Product Owner versus Scrum Master boundary: the Product Owner decides what gets built and in what priority, while the Scrum Master protects the process and removes impediments. Assuming a project manager simply replaces both is a common distractor.

A retrospective is a structured team ceremony held at the close of each iteration or sprint, focused on inspecting and improving the team’s working process rather than the product. The team examines what went well, what did not, and what to change next, committing to at least one actionable improvement. On the PMP exam, the key distinction is that a retrospective targets process improvement within an agile or hybrid team, whereas lessons learned captures knowledge at the project or phase level. Retrospectives are iterative and forward-facing within the same project, making them the answer for improving team performance mid-project.

Lessons learned are documented knowledge — positive and negative — captured continuously as a project progresses, not just at close. They are recorded in the lessons learned register, a live project-level artifact updated throughout execution, then transferred at close into the organizational lessons learned repository, an organizational process asset (OPA) future teams reuse. The exam trap is confusing the two: the register is the working in-project log; the repository is the permanent organizational store. On predictive projects the register is built during execution and finalized at closing; on agile or hybrid projects, retrospectives capture the same learning iteratively and feed the same repository.