Agile Roadmaps: Planning Ahead Without Pretending to Know Everything
By Sebastiaan Jansen · · 7 min read
An agile roadmap is a living plan of outcomes, ordered by horizon, that a team updates as it learns. It says what you intend to achieve soon, what you will explore next, and what you are only watching. A date six months out is not a promise.
People look for this when the quarterly slide has drifted from the tickets they ship. Direction can stay stable while the order of problems changes, and dates appear only where the team has evidence.
What an agile roadmap refuses to promise
A fixed roadmap lists features with end dates. A horizon plan lists bets. The Scrum Guide puts a product goal above each sprint and lets the sprint plan change, so the goal holds while the details are allowed to be wrong.
Call it an agile development roadmap when engineering, design, and go-to-market share one page. Outcomes sit on that page, and solutions sit underneath where they can be swapped.
Three things do not belong as commitments:
- A feature name with a month attached, when nobody has sliced the work or measured a similar slice.
- A capacity number copied from last quarter that ignores support, hiring, and leave.
- A stakeholder request written as a delivery because saying no felt expensive.
Park them in a later column, a list, or a discovery ticket.
What to put on the page
A new teammate should be able to read the page in ten minutes. A product roadmap your team will use has the same bones: an outcome, an owner, and a link to real work. Say how often you review it and what evidence can move a bet.
| Column | Time horizon | What you write | What you do not write |
|---|---|---|---|
| Now | This cycle, or the next two to six weeks | One outcome, the tickets that serve it, a confidence note | A pile of unrelated requests |
| Next | The following one or two cycles | Problems you expect to start, with a reason | Start dates treated as contracts |
| Later | Beyond that, often a quarter or more | Themes and options you might fund | Month-level dates |
| Not now | Unscheduled | Ideas you have seen and chosen to leave | Silent deletion of someone's request |
Each row needs an owner, an outcome, and a link to the work. A row without those is a wish, and wishes belong in Later.
Write confidence as a word:
- Committed: sliced, compared with a similar cycle, and accepted in planning.
- Directional: the outcome is agreed, but the solution or the date can still move.
- Exploring: you are paying to learn, so one shipped feature is not the test of success.
A now-next-later roadmap is the simplest layout that enforces this. Date Now only when the work is committed, and leave Later undated. If every column has months in it, you have a fixed plan with a flexible label.
A worked example: Northline Billing
Northline is a fictional billing product with one team of eight. Support wants retries, sales wants self-serve plan changes, and the CEO wants a revenue view that finance trusts. None of it is sized.
Now, this six-week cycle: failed invoices retry without a ticket. Confidence is committed because a similar gateway fix took nine days. Three tickets cover the top failure, that retry, and a support macro. The date is the agreed cycle end.
Next: a finance admin moves an account between plans without engineering. Confidence is directional. Billing states are known but proration is not, so discovery is a ticket with a question. Sales may say the work is being shaped, not that it ships on 12 May.
Later is a trusted weekly revenue view, with no solution and no date. Not now holds a reseller portal, a mobile app, and a PDF rebrand, each with a one-line reason.
At review a second gateway appears, and proration is blocked on an unwritten finance rule. Now gains one retry slice, Next becomes "blocked on a finance rule," and Later stays. The page still matches the tickets.
How to build an agile roadmap
If you skip the evidence step, you end up with a poster.
1. Name the outcomes, not the backlog themes
"Platform" hides five bets, while "Failed invoices retry without a ticket" is something you can finish. Tie each outcome to a company goal when you have one. A strategic roadmap sits above this page, which holds the sequence the team can start.
2. Sort by horizon using capacity you have already seen
Count work done in the last two or three cycles, including review and release. That is the budget for Now. Next is what you expect to start, plus slack for spillover. Later gets no math. Slice until the first slice fits in Now, and let the rest earn a place in Next at the following review.
3. Attach work, or mark the row as discovery
Now points at current tickets. Next points at a decision, a spike, or a draft slice. A row with none of those is a sentence on a slide. Some tools draw a bar that no issue supports. A roadmap counted from tickets, which is how Falrow draws one, cannot show that orphan bar.
4. Write the confidence and the review date
Put confidence on each row and the next review date in the header, set on the cycle boundary you already use. Cycle schedules with reviewed rollover, as Falrow runs them, make you look at unfinished work instead of copying it forward. A calendar invite with the same rule also works.
5. Publish one page and say what a date means
Name the column that can be promised. At Northline only Now is a commitment, and only through the cycle end. Next is direction, and Later is a conversation. For anything further out, offer a range based on finished work or a smaller slice.
6. Change the page when the evidence changes
Move a row when discovery answers a question, when a slice slips for a reason you can name, or when a goal above the page changes. Leave it when a request was only eloquent. Note each move in three lines.
How this differs from a project plan
A project plan sequences tasks for known work. A horizon plan sequences outcomes while the scope is still partly unknown. The task plan lives under a Now outcome, and the agile roadmap decides which outcome gets one.
A project roadmap fits a bounded delivery with a real end, such as a migration. A day-level Gantt chart for unopened work is the same false promise in another template. If finishing the item ends the effort, you are planning a project. If the backlog keeps going, you are writing a roadmap.
Where dates earn a place
Spend dates on Now. "Review on Thursday" and "committed for the cycle end" can be checked. A month on Later is usually a quarter typed into a spreadsheet.
A forecast is not a date. Cycle-time history can show where a remaining slice usually lands. Falrow runs a Monte Carlo forecast of 2,000 runs on the same tickets the roadmap shows. The range is only as good as that history, so for a new team or unestimated epics it stays wide. On paper, compare the slice with recent similar ones and quote a window.
Jira boards and timelines can hold all of this, and that same flexibility is what creates orphan bars. Read the limits of Jira roadmaps before the timeline becomes the plan of record. The plan of record should be the tickets the team has accepted.
How to review without restarting
Forty-five minutes, with the page and unfinished work open:
- What reached done, and did the outcome move?
- What is still open in Now: should it stay, shrink, or split?
- What in Next is ready for the next cycle?
- Did anything new beat a current row?
- What was parked, and who needs a one-line note about it?
A missed ticket gets pulled forward on purpose or sent back to Next. Copying leftovers forward hides over-commitment. Publish the page beside the tickets: either count the roadmap from them, or ban slide edits that skip the ticket.
What to hand someone who asks for the plan
Hand over the one-page plan, the Now tickets, a three-line review note, and the sentence that says what a date means. That packet replaces the quarterly slide. Keep a ticket under every commitment, and if someone wants more certainty than the work supports, shrink the slice.
FAQ
What is an agile roadmap?
An agile roadmap is a short, regularly reviewed plan of product outcomes arranged by horizon. Near-term rows name a result and point at committed work. Later rows name problems or themes without turning them into dated promises. The team rewrites the sequence whenever a cycle, a discovery, or a company goal gives it new evidence.
How is an agile roadmap different from a release plan?
A release plan covers one specific ship: its scope, a quality bar, and a date or window you will stand behind. The horizon plan is the sequence of outcomes across releases. One Now row might contain a release plan, but the Later column should not. If every row has a release date, you have a calendar rather than horizons.
How far ahead should an agile roadmap look?
Far enough to show direction, and no further than you can honestly describe outcomes. A practical shape is a committed cycle of two to six weeks, a next horizon of one or two cycles, and later themes without months. Four quarters of themes is fine. Four quarters of dated features is not.
How often should you update it?
Update it at the planning and review boundary you already use, and whenever a discovery closes or a commitment slips. If you do not run cycles, a monthly edit is a fair default. Avoid editing it during status meetings, because unlogged tweaks are how the page stops matching the work.