Does Agile have a project plan? Yes. The plan changes as the team learns, and it is usually more detailed for the work that is about to happen than for work further away.

A roadmap can help explain direction over time, but it is not the whole project plan. A team still needs to understand the intended outcome, the work, dependencies, people, costs, decisions and any approvals that matter. Let’s look at how to plan without pretending that every detail is known on day one.

Agile is an approach, not one fixed planning method

“Agile” covers a family of ways to organise and deliver work. Scrum and Kanban are different approaches; they do not use the same planning rhythm. Teams also combine iterative delivery with fixed procurement, regulatory checks, funding dates or other organisational controls.

So, before you borrow a process from a book or tool, check what the team has actually agreed to use. Is there a Sprint Goal and a Sprint Review? Is work pulled through a flow system? Is a supplier delivering a fixed contract? These details change what planning is useful.

The Scrum Guide describes Scrum as a framework with a Product Goal, Product Backlog, Sprint Goal and a plan for each Sprint. The current official Scrum Guide is the November 2020 edition. The Kanban Guide, May 2025, focuses on defining and managing a workflow and improving flow. A Kanban team does not need to invent Sprints to have a plan.

Plan at different levels of detail

In an adaptive approach, the level of detail changes with how near and how well understood the work is. You can make a useful longer-range plan without turning every possible task into a promise.

• Direction: the problem, intended outcome, users or beneficiaries, boundaries and decision authority.
• Roadmap or forecast: the larger outcomes or releases the team expects to explore, with assumptions and confidence visible.
• Near-term delivery: the next milestone, release, Sprint or replenishment of work, including its dependencies and acceptance needs.
• Daily work: who is doing what next, what is blocked, and what should change based on new evidence.

In Scrum, the Developers create a plan for the Sprint that supports the Sprint Goal, then adapt it as they learn. In Kanban, the team makes its workflow and policies visible, manages work in progress and uses flow information to discuss what can be forecast. The details differ; neither approach means “no plan”.

A roadmap is direction, not a promise of exact dates

A roadmap is useful when it helps people see why the work matters and what outcomes may come next. It can show themes, intended releases or decision points. It should also make uncertainty visible.

For example, a roadmap might show “make appointment changes easier” as a near-term outcome and “reduce manual follow-up” as a later opportunity. The team may not yet know which features will achieve the later outcome. Put the work that is understood into the near-term plan; record the open questions that need research or a decision.

A roadmap can be a forecast or a direction of travel. If a date is a firm commitment because of a contract, policy or business event, say so and explain what is fixed, what can change and who can approve a trade-off. Do not colour every roadmap item as a committed delivery date.

What belongs in an Agile project plan?

The project still needs enough planning to make sound decisions and coordinate people. A short planning note can bring together:

• Outcome and value: what should change, for whom and why?
• Scope and boundaries: what is included, excluded or still being explored?
• Delivery approach: what is iterative, what is fixed, and how will the team review progress?
• Forecast: what is expected next, what assumptions support it and how confident are we?
• Dependencies and capacity: what relies on another team, supplier, approval or scarce specialist?
• Costs and constraints: what funding, dates, quality requirements or service conditions matter?
• Governance: who can decide changes, accept outputs and resolve issues outside the team’s authority?
• Release and transition: what needs to be ready for users, support teams, training and operations?

This does not have to become eight separate documents. Use the records your organisation requires, then keep the remaining information in a place the team can maintain.

Example: improving online appointments

This is an illustrative example. A service team is asked to make online appointments easier to change. The sponsor has an agreed funding limit and wants to see progress before the next planning cycle. The exact solution is not known yet, and the team needs input from customer support and the policy owner.

A practical plan might say:

• Outcome: customers can change an appointment with fewer avoidable calls. The team will agree a baseline and measure before claiming improvement.
• First step: review the current journey with customers and support staff; document the main failure points.
• Next delivery: test a small change with a limited group, subject to policy approval and accessibility checks.
• Dependencies: support capacity, booking-system access and the policy owner’s review.
• Forecast: show the next review date as planned; keep later release dates provisional until the test results and technical estimate are available.
• Decision: the sponsor decides whether to fund wider rollout after reviewing the evidence and impact.

The team can plan the first test in detail while keeping the wider path flexible. If the test shows the change does not address the main problem, the project has learned something before committing to a larger build.

How to make a plan the team can use

1. Agree the outcome. Ask the sponsor and team to describe the result in plain language. Record how you will know whether it is useful.
2. Identify the fixed points. Separate contractual or required dates from preferences. Confirm who has authority to change them.
3. Make dependencies visible. Name the other team, supplier or decision owner, and ask when you need their response.
4. Plan the next slice of work. Define what can be completed or tested, what “done” means and who will review it.
5. Show uncertainty honestly. Use a range, confidence note or provisional date when a precise commitment is not supported by evidence.
6. Review and adjust. Use user feedback, progress and new information to revisit the forecast. Record material changes and their impacts.

If the team uses Scrum, check that Sprint Planning results in a Sprint Goal and a plan the Developers own. If it uses Kanban, check that work, policies, blockers and flow are visible. A status meeting that updates a chart without helping anyone choose or act is not much of a planning system.

What about my Japan trip example?

In an earlier version of this article, I used the trip I took to Japan in 2018 to explain flexible planning. I still like the basic idea: I had a reason for the trip and fixed travel dates, but the daily itinerary could change as we learned more and decided what we wanted to do.

It is an analogy, though, not a project delivery method. A work project may include contracts, service readiness, security, policy approval, funding limits and people who are affected by a change. The team must plan for those responsibilities as well as adapt its delivery.

Keep planning visible and proportionate

The UK Government’s guidance on planning in agile recommends planning at the right level and making the plan visible. Its Project Delivery Functional Standard, version 2.1 (2025) sets expectations for UK government projects, including governance and planning. These are useful references, but they do not automatically replace your organisation’s own policies or contractual obligations.

Agile planning is not an excuse to avoid dates, governance or accountability. It is a way to plan with the evidence you have, learn through delivery and update the forecast when reality changes. Start with a clear outcome and a useful next step, then keep the wider plan honest as you learn.