The five phases Envision, Speculate, Explore, Adapt and Close form a particular agile project-management lifecycle described by Jim Highsmith. They are a way to organize discovery and decisions when a project cannot know every requirement in advance. They are not five universal stages prescribed by the Agile Manifesto, nor are they the formal examination syllabus of every modern agile certification.
The useful distinction is that a phase describes the decision the team is making, not an excuse to hold a meeting or complete a template. A product team may explore, adapt its priorities and explore again several times before a release. Projects with mandatory safety, privacy or contractual requirements still need the appropriate controls throughout the cycle; agility does not make such obligations optional.
Why the five-phase model is different from a linear project plan
A strictly sequential plan may assume that all features can be detailed, approved, built and finally tested once. In uncertain work, that delay can make a false assumption expensive to uncover. Highsmith’s model instead creates a bounded vision, a provisional hypothesis about delivery, iterative exploration, deliberate adaptation and a decision to close and transfer the result.
Consider a hypothetical regional clinic trying to reduce the time patients spend booking appointments. The team knows it must respect clinical safety, privacy and accessibility, but cannot yet predict whether users will prefer web bookings, assisted telephone booking or an integration with an existing patient portal. The unknown part belongs in small, ethically reviewed experiments rather than a large unrevised specification.
The model should not be mistaken for a promise that agile always delivers faster or cheaper results. Frequent testing creates learning opportunities; it does not automatically eliminate procurement, data migration or organizational dependencies. The project lifecycle choice still depends on uncertainty, consequence of failure, stakeholder authority and available feedback.
Phase 1: Envision the outcome and the boundaries
Envision asks what problem justifies the work, who experiences it and what outcome will count as useful. For the clinic, “build an appointment app” is an output, not yet a measurable objective. A stronger vision is that people can request eligible appointments with fewer repeated calls, while staff can confirm what was requested and when. The team should decide how it will observe booking completion, accessibility and operational burden.
Name the stakeholders who must make or review decisions. Patients, reception staff, clinical management, privacy specialists and the technology team may have different concerns. A privacy officer may prohibit using real records in a prototype; clinicians may require a manual review for urgent symptoms. These constraints belong in the vision rather than being discovered as a late exception.
Create a concise decision record: beneficiary, problem, expected value, non-negotiable safety constraints, sponsor, product owner or equivalent decision authority, and the first evidence to collect. It is not necessary to write a detailed list of every screen or future feature. The agile project charter can help capture authorization without implying the plan will never change.
A practical Envision failure is settling on a technology before finding out whether users can access it. For instance, a smartphone-only option may exclude people who need an assisted booking channel. Invite representative users to test assumptions early, use consent and accessible research methods, and distinguish a genuine service need from enthusiasm for a particular tool.
Phase 2: Speculate about an achievable first release
Speculate does not mean guessing without discipline. It means planning with explicitly stated uncertainty: what the team currently believes, which dependencies can be checked, what scope is worth trying and which facts would change the decision. The first plan is a hypothesis, not a contract that every lower-priority idea will be delivered.
For the clinic, an initial six-week pilot might cover only booking requests for one non-urgent service, with manual confirmation and no direct integration to the medical record. The hypothetical six-week limit is a planning constraint for this example, not a recommended standard duration. The team must still determine whether security review, user testing and operational acceptance fit that window before making a commitment.
Classify work by uncertainty as well as apparent urgency. Existing single-sign-on integration might be predictable, while matching appointment availability across several incompatible systems may be highly uncertain. Test the risky assumption first with a small technical demonstration and representative workflow, rather than leaving it behind simpler visual features until the end.
Make risks and dependencies visible. An external messaging supplier, a data-retention rule and an accessibility audit can all change the scope of the pilot. A project risk response should name the uncertainty, owner, trigger and permissible response; a colored risk box without decision authority is not a sufficient plan.
Phase 3: Explore through constrained delivery and feedback
Explore is where the team turns a selected hypothesis into something that can be observed: a prototype, service increment, trial workflow or technical experiment. Work proceeds in a way that makes mistaken assumptions visible. Depending on the team and product, exploration may include design, coding, supplier investigation, training and changes in daily operating practice.
Suppose the clinic tests a booking-request form with a handful of consenting participants using invented patient information. The team can observe whether users understand the available appointment types, whether keyboard navigation works and whether reception staff can find incomplete requests. The test should be reversible, with no accidental notifications sent to real patients.
A Scrum team may organize this work in Sprints and inspect an increment, while a Kanban-oriented service team may use a continuous flow. The project model does not require every agile team to use Scrum, and the Scrum delivery framework does not replace decisions about clinical acceptance, budget authorization and wider project governance.
Define completion carefully. A developer saying a form works on a personal computer is not the same as testing privacy controls, accessibility, error recovery and operational ownership. Useful acceptance criteria identify observable behavior, not just a promise that the page looks finished.
Keep experiments small enough to interpret. If the team changes the booking workflow, notification text and patient eligibility rules together, it may struggle to explain why completion rates moved. When the learning goal is important, vary fewer conditions or record confounders so that conclusions are not invented from a handful of anecdotes.
Phase 4: Adapt deliberately instead of calling every change progress
Adapt asks what the team learned and what that evidence requires it to change. In the clinic pilot, users may complete the form successfully but reception staff may spend more time resolving ambiguous appointment requests. That is not a pure success. The team should compare its intended outcome with the operational cost and decide whether to change the language, add a clarifying step or abandon an assumption.
An adaptation review should separate evidence, interpretation and decision. Evidence could be a high proportion of incomplete requests in the test sample; interpretation might be that a label is unclear; the decision is to test a revised label or workflow. Without this separation, the loudest stakeholder can turn an opinion into a supposed measurement.
Adaptation does not authorize a team to bypass a fixed requirement. A legal retention obligation or a clinical safety rule remains a condition to meet, not a negotiable backlog item. The team may choose a narrower release or seek an authorized scope change. The measure of delivered value is whether the actual service improves the intended result without unacceptable collateral risk.
After the decision, the team returns to exploration with a changed hypothesis. This loop may happen within a Sprint, between releases or across project stages. Envision can also need revision when the underlying problem changes; the five named phases are a learning structure, not a one-way conveyor belt.
Phase 5: Close with acceptance, transfer and evidence
Close is more than declaring that the final backlog item moved to Done. The clinic needs a conscious decision about operational handover: who maintains the service, where staff find support, which risks remain, whether users have the necessary accessibility support and whether records will be retained or disposed of appropriately. A product may need ongoing enhancement after the project closes.
An effective closure record distinguishes what was accepted, what remains deferred and what needs an owner. If a limited pilot never met the privacy or safety conditions for wider use, closing the project may mean recording a stopped initiative rather than forcing a launch. Responsible cancellation can be a valid outcome of an experiment that prevented a costly mistake.
Lessons learned should point to decisions that future teams can reuse. “Improve communication” offers little guidance. “Reception staff were not included in the first workflow test, which concealed a manual reconciliation step” identifies a preventable process failure. The project handover and closure connection is where agile delivery meets ongoing organizational accountability.
Put the five phases to work without manufacturing bureaucracy
At the start of a project, ask for one meaningful artifact per decision rather than a large template library. Envision may need an outcome statement and authority map; Speculate needs assumptions and a short plan; Explore needs demonstrations and test evidence; Adapt needs a recorded decision; Close needs acceptance and an owner for remaining work. The form can be lightweight as long as the evidence survives staff changes.
Review the rhythm of stakeholder involvement. The product team might inspect progress daily while clinical, financial and privacy decisions occur at defined checkpoints. A stakeholder engagement approach should match authority and information needs rather than treating every participant as an identical recipient of frequent status reports.
Select tools only when they improve a real observation. A visual board can make work in progress visible; a repository can retain test history; a shared decision log can explain why the pilot scope changed. None of them constitutes evidence of business benefit simply because the team uses the software, and none is mandatory in Highsmith’s description.
Distinguish Highsmith’s phases from current certification frameworks
The five-phase vocabulary originated as one agile project-management model. It should not be presented as the official syllabus of every AgilePM, Scrum or PMI credential. For example, APMG AgilePM Version 3 emphasizes governance, value, leadership and integration with Scrum-based product delivery, while a Scrum Master qualification focuses on the Scrum framework’s accountabilities and events. Similar words do not make the assessment structures interchangeable.
A reader may still use the five phases to examine a real project, independent of any exam: What is the intended outcome? Which assumptions are being tested? What evidence did exploration produce? What changed as a result? Who accepted and now owns the work? The model is most useful when those questions reveal a missing decision before it harms a customer.
This is why closing the feedback loop matters more than chanting five phase names. An adaptive team can change its plan while still protecting privacy, safety, quality and authorized budgets. The result to seek is an evidence-based service improvement, not a claim that every project is now agile merely because its plan includes an Explore or Adapt column.