Agile project management treats project phases as a recurring pattern for learning, delivery, and adjustment rather than sequential checkpoints used in Waterfall.
The clearest five-phase model for Agile project management is James Highsmith’s Agile Project Management cycle: Envision, Speculate, Explore, Adapt, and Close. This article uses that model consistently because it reflects how Agile work actually happens: teams establish a direction, make an informed plan, build in short cycles, inspect the result, and close out learning before continuing or releasing.
This distinction matters because many summaries of Agile phases accidentally mix Agile with traditional project management language such as initiation, planning, execution, monitoring, control, and closure. Those terms are useful in many governance environments, but they can make Agile sound like a Waterfall process with shorter deadlines. Highsmith’s model gives project managers, Scrum Masters, Product Owners, engineering managers, and stakeholders a better vocabulary for iterative work without losing discipline.
What the five phases mean in Agile project management
The five phases are best understood as a cycle rather than a one-time sequence. A team may move through all five across a product release, repeat parts of the cycle inside a sprint, and revisit Envision when market feedback or stakeholder priorities change. The model supports structure, but it does not depend on stage gates that freeze scope before delivery begins.
- Envision: clarify the product vision, business problem, users, goals, constraints, and success measures.
- Speculate: create a realistic, change-tolerant plan using hypotheses, backlog items, priorities, and near-term forecasts.
- Explore: build and test increments of value through short delivery cycles.
- Adapt: inspect results, feedback, risks, and team performance, then adjust direction or execution.
- Close: complete a release, feature, sprint goal, or project slice by confirming outcomes and capturing learning.
In Scrum terms, Envision often shapes the Product Goal and early Product Backlog. Speculate appears in backlog refinement and Sprint Planning. Explore takes place during the Sprint as the team creates a usable Increment. Adapt is visible in Sprint Review and Sprint Retrospective, where product feedback and process feedback are examined separately. Close may happen at the end of a sprint, a release, or a larger project cycle when the team confirms what was delivered and what should be carried forward.
Envision: create shared direction before planning detail
The Envision phase gives the work a reason to exist. It is where stakeholders, product leadership, delivery teams, and relevant business representatives align on the problem to solve, the users affected, the expected value, and the boundaries that matter. The output is not a fixed specification. It is a shared understanding strong enough to guide decisions when uncertainty appears.
In a Scrum environment, Envision commonly informs the Product Goal, initial Product Backlog themes, stakeholder map, working agreements, and Definition of Done. In Kanban, it may shape service expectations, classes of service, intake policies, and the criteria used to decide which work enters the system. The Product Owner or product lead is usually accountable for product direction, but the phase works only when delivery and business stakeholders contribute realistic constraints, risks, and assumptions.
Good Envision work can be measured by clarity rather than document volume. Useful signals include whether stakeholders can describe the same problem in plain language, whether the team understands the target users, whether success measures are specific enough to guide prioritisation, and whether major assumptions have been made visible. A common mistake is to rush from a vague vision into sprint execution, which often creates churn later because the team is busy without being aligned.
Speculate: plan with uncertainty in view
Speculate is Highsmith’s deliberate alternative to pretending that early plans are certain. The team forms a working forecast, identifies features or outcomes, estimates enough to make responsible decisions, and sequences work in a way that can change when evidence changes. The point is not to avoid planning. The point is to plan in a way that remains honest about incomplete information.
In practice, Speculate includes backlog creation, refinement, release forecasting, dependency discussion, risk identification, and Sprint Planning. A Product Owner may prioritise backlog items according to value and risk, while developers help clarify size, technical implications, and sequencing. Scrum Masters, Agile coaches, or project managers often help expose hidden dependencies and keep the plan lightweight enough to be revised.
The most useful artifacts are a prioritised Product Backlog, a near-term sprint or flow plan, acceptance criteria, a Definition of Ready where the team uses one, and visible assumptions. Metrics should focus on forecast realism and readiness. For example, a team can look at whether high-priority backlog items are sufficiently understood before Sprint Planning, whether dependencies are being discovered too late, and whether forecasted work regularly exceeds actual capacity. Over-speculating is a frequent anti-pattern: long roadmaps become treated as commitments, and the team loses the ability to respond to learning.
Explore: build usable increments and learn from real work
Explore is the delivery phase, but it should not be reduced to coding or task completion. The team designs, builds, tests, integrates, reviews, and improves a working product increment. Quality assurance belongs inside this phase as a continuous activity, not as a separate phase at the end. When QA is isolated after development, feedback arrives late and Agile becomes a mini-Waterfall pattern.
Scrum teams experience Explore during the Sprint. Kanban teams experience it as work items move through their flow from commitment to completion. In both cases, the strongest signal of progress is working, tested value rather than percentage-complete reporting. Developers, testers, designers, analysts, Product Owners, and stakeholders may all contribute, but the team needs a clear Definition of Done so that “finished” means integrated, reviewed, and fit for use according to agreed standards.
Practical metrics include cycle time, escaped defects, work item ageing, deployment frequency where relevant, and the amount of rework caused by unclear requirements. Tooling can support this phase through backlog boards, automated tests, CI/CD pipelines, feature flags, test environments, and documentation spaces, but tools do not replace working agreements. A board that shows movement is useful only if the team also discusses blocked work, quality risks, and whether the increment still supports the intended outcome.
Adapt: inspect evidence and change responsibly
Adapt is where Agile earns its name. The team compares what it expected with what actually happened, then adjusts product direction, technical approach, process, or stakeholder expectations. This phase includes product learning from users and stakeholders as well as delivery learning from the team itself.
In Scrum, the Sprint Review supports product adaptation by examining the Increment and discussing what should happen next. The Sprint Retrospective supports process adaptation by examining how the team worked and what could improve. These events serve different purposes, and combining them too casually can weaken both. Stakeholder feedback should influence product choices, while retrospective insights should improve collaboration, quality, flow, and sustainability.
Adapt can be measured by change lead time, the speed at which feedback is reflected in backlog decisions, the number of repeated retrospective issues, and whether risks are being reduced over time. Lightweight governance fits naturally here. A steering group, sponsor, or portfolio forum can review evidence, value, budget, and risk without forcing the team through heavy approval gates after every iteration. Definitions of Done, working agreements, risk logs, and decision records provide control while preserving Agile responsiveness.
Close: finish the loop and preserve learning
Close is often misunderstood because Agile teams expect more work to follow. In Highsmith’s model, Close does not necessarily mean the whole product is finished. It can mean closing a sprint, a release, an experiment, a feature, or a project initiative in a disciplined way so the organisation knows what was delivered, what value was achieved, and what should be learned.
Typical activities include confirming acceptance, communicating release notes or outcomes, resolving open decisions, archiving useful documentation, reviewing operational readiness, and capturing lessons that should affect future work. A Product Owner may confirm whether the intended value was achieved, while the delivery team may document technical follow-up, support considerations, and improvement actions.
Useful measures include value realisation, adoption signals where available, unresolved defects or support issues, stakeholder satisfaction with the outcome, and whether lessons learned become actionable backlog or process items. Skipping Close is a subtle but costly habit. Teams move quickly into the next sprint or release, but the same defects, dependency problems, or unclear ownership patterns reappear because learning was never converted into action.
How the phases work together in a sprint or release
Consider a product team adding a new self-service password reset feature for internal employees. During Envision, the team clarifies the problem: support requests are taking too much time, employees need a secure way to recover access, and the organisation must satisfy security requirements. The Product Owner defines the intended outcome, while security, support, and engineering stakeholders agree on constraints and success signals.
During Speculate, the team breaks the work into backlog items such as identity verification, user interface changes, notification handling, audit logging, and support documentation. Sprint Planning selects a thin but usable slice, perhaps enabling the reset journey for one user group first. Risks are made visible early, including integration with identity systems and the need for clear audit records.
During Explore, the team builds the selected slice, tests edge cases, reviews security behaviour, and integrates the feature behind a controlled release mechanism. Feedback may come from a small user group or internal stakeholders before wider release. The team does not wait for a separate testing phase; quality checks run throughout the work.
During Adapt, the Sprint Review reveals that the reset flow is understandable, but employees are confused by one verification step. The backlog is updated, and the Retrospective identifies that security acceptance criteria should be clarified earlier for similar work. During Close, the team records the outcome, confirms what is ready for release, documents operational notes for support, and carries forward improvement actions into the next cycle.
This example shows why Agile phases are iterative. The team still plans, executes, reviews, governs risk, and closes work, but it does so through repeated learning loops. Scope can change, yet decisions remain visible and accountable.
Agile governance without Waterfall stage gates
Agile does not remove governance. It changes the timing and texture of governance so that control is based on transparency, evidence, and frequent inspection rather than large approval moments separated by long periods of hidden work. This is especially important in regulated, security-sensitive, or multi-team environments where leaders still need confidence that risk is being managed.
In Envision, governance means clarifying outcomes, constraints, stakeholders, and risk appetite. In Speculate, it means making assumptions, dependencies, and forecast confidence visible. In Explore, it means using Definitions of Done, automated checks, peer review, and work-in-progress limits to protect quality. In Adapt, it means reviewing evidence and making conscious trade-offs. In Close, it means confirming outcomes and ensuring that lessons, defects, and operational responsibilities are not lost.
Scaling adds another layer. Multiple teams may need shared objectives, a common Definition of Done, aligned release expectations, and coordination forums such as Scrum of Scrums or similar cross-team planning sessions. The challenge is to synchronise learning without centralising every decision. Shared artifacts help teams align, while local teams retain enough autonomy to solve the problems closest to their work.
Common mistakes when applying the five phases
The first mistake is treating the model as a linear lifecycle. Teams may Envision once, Speculate heavily, Explore for several months, Adapt near the end, and Close after delivery. That pattern uses Agile terms but removes the feedback that makes the model useful. The phases should recur at different levels of scale, from sprint to release to product strategy.
A second mistake is freezing scope between sprints because an early roadmap was interpreted as a contract. Roadmaps are valuable when they express intent, sequence, and trade-offs. They become harmful when they prevent the team from responding to user feedback, technical discovery, or changed business priorities.
A third mistake is skipping Adapt because the team is under pressure to deliver. Retrospectives, reviews, and feedback discussions can feel optional when deadlines are tight, but removing them often increases rework. Adaptation is the mechanism that keeps delivery aligned with value and quality.
Finally, teams sometimes create a separate QA phase after Explore. That usually delays defect discovery and weakens ownership of quality. Agile teams benefit more from embedding quality into daily development through acceptance criteria, test automation where appropriate, exploratory testing, peer review, and a Definition of Done that the whole team respects.
Applying the model in professional practice
The five-phase model is useful because it gives teams a common language without forcing them into a rigid method. Scrum teams can map it to Product Goals, Product Backlogs, Sprint Planning, Increments, Sprint Reviews, Retrospectives, and release closure. Kanban teams can map it to intake policies, replenishment, delivery flow, service review, improvement work, and completion criteria.
Project managers transitioning from Waterfall should pay particular attention to the difference between control and prediction. Agile control comes from short feedback cycles, transparent work, visible risks, clear definitions, and regular stakeholder engagement. It does not require pretending that all requirements can be known at the start.
Readynez covers Agile project management as part of its training portfolio, but the practical value of the model comes from how consistently teams use it in daily decisions. A team that can explain its vision, maintain a realistic backlog, deliver tested increments, adapt from evidence, and close learning loops is applying Agile project management in a disciplined way.
References and further reading
The five-phase structure used here follows James Highsmith’s Agile Project Management model: Envision, Speculate, Explore, Adapt, and Close. Readers comparing this model with Scrum should also consult the Scrum Guide for the current definitions of Scrum roles, events, artifacts, the Product Goal, and the Increment.
For broader context, the Agile Alliance provides explanations of Agile principles and common practices, while PMI materials can help organisations understand how Agile delivery interacts with portfolio, programme, and project governance. These sources use different lenses, so the important step is to avoid merging incompatible phase lists into one confused lifecycle.
Using the five phases to improve delivery
The key takeaway is that the five phases of Agile project management are not a substitute for Scrum, Kanban, or good product leadership. They are a practical lens for understanding how Agile teams move from direction to planning, delivery, feedback, and closure while keeping learning active throughout the work.
A practical next step is to review a current sprint, release, or initiative against the five phases. If the vision is unclear, strengthen Envision. If the backlog is unstable for the wrong reasons, improve Speculate. If quality arrives late, examine Explore. If feedback is ignored, repair Adapt. If lessons disappear after delivery, formalise Close. Teams that want guided preparation for Agile project management certification can use Readynez training as a structured way to connect these concepts with exam objectives and workplace application.
FAQ
What are the five phases of Agile project management?
The five phases in Highsmith’s Agile Project Management model are Envision, Speculate, Explore, Adapt, and Close. Envision defines direction, Speculate creates an adaptable plan, Explore builds usable increments, Adapt responds to feedback and evidence, and Close confirms outcomes while preserving learning.
Are Agile phases the same as Waterfall phases?
No. Waterfall phases are usually treated as sequential stages, while Agile phases repeat across iterations, releases, and product decisions. Agile teams still plan, deliver, review, and close work, but they do so in shorter feedback cycles that allow priorities and solutions to change.
How do the five phases map to Scrum?
Envision often shapes the Product Goal and early backlog direction. Speculate appears in backlog refinement and Sprint Planning. Explore happens during the Sprint as the team creates an Increment. Adapt is supported by the Sprint Review and Sprint Retrospective. Close occurs when a sprint, release, feature, or project slice is accepted, communicated, and learned from.
Is testing a separate Agile phase?
Testing should not be treated as a separate final phase in Agile delivery. Quality activities belong throughout Explore and are reinforced by acceptance criteria, automated checks where appropriate, peer review, exploratory testing, and the Definition of Done.
How can teams use the five phases without creating too much process?
Teams should keep the phases lightweight and evidence-based. The model works best when it improves conversations about direction, planning, delivery, feedback, and learning rather than creating extra documents for their own sake. A small number of clear artifacts, visible risks, and regular inspection points usually provide enough structure.
