Project Roadmap & Milestones Markdown Table Template
A roadmap table tells people what a team intends to build, roughly when, and in what order. Its readers want different things from the same rows. Contributors to an open-source project look for where help is wanted, customers check whether the feature they asked for is coming before their renewal, investors look for momentum, and the team itself uses it to say no to work that is not on it.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The hard part is not the format but the honesty of the dates. Near-term rows can carry a quarter with reasonable confidence; anything two or three quarters out is a statement of intent, and a table that presents both with the same certainty sets up disappointment. Many teams handle this by using quarters only for committed work and coarser buckets — Now, Next, Later — for the rest, or by adding a confidence column.
A roadmap also decays faster than almost any other document. A row showing “In Progress” for a quarter that ended a year ago signals that nobody maintains the page, and readers will assume the rest is fiction too. The useful habits are small: a “Last updated” date above the table, a review on a fixed cadence, links from each row to the issue or epic where real progress is tracked, and moving shipped items to a changelog rather than leaving them to pile up.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Milestone Initiative | left :--- | The outcome or capability, named so a non-engineer understands it (“Real-time collaborative editing”), ideally linked to its tracking issue or epic. Left-aligned. Avoid internal codenames unless the audience already knows them. |
| Target Timeline | center :---: | A quarter (Q3 2026) for committed work, or a horizon (Now, Next, Later) for intent. Centered. Say whether quarters are calendar or fiscal if they differ, and never give exact days on a public roadmap unless they are contractual. |
| Status | center :---: | A small fixed vocabulary, each with one emoji and a word so it still reads when emoji render poorly: ✓ Shipped, ⚡ In progress, 📅 Planned, 💡 Exploring. Centered. Define the set in a legend and do not invent new states per row. |
| Technical Lead | left :--- | The accountable person or team for the initiative. Left-aligned. On a public page a team name is fine; internally, name a person so questions have somewhere to go. Use the GitHub team handle (@org/frontend) if the table lives in a repository. |
| Primary Deliverable | left :--- | The concrete artefact that marks the milestone as done: a released package, a command, a GA feature flag. Use backticks for commands or package names. Left-aligned. If you cannot name a deliverable, the initiative is not ready for a date. |
How to Fill It In
- 1Pull candidate initiatives from the issue tracker’s epics or milestones, along with their current state. The roadmap should summarise the tracker, not compete with it as a second source of truth.
- 2Ask each lead for the target quarter and their confidence. Put committed work in dated rows and move low-confidence items into a Later bucket or mark them as exploring.
- 3Name one deliverable per row and link the row to its epic. Check that each Status matches what the tracker shows today.
- 4Order rows chronologically, put a “Last updated: YYYY-MM-DD” line above the table, and add a one-line disclaimer on public roadmaps that plans can change.
- 5Schedule a review at a fixed cadence, such as the first week of every quarter. Move shipped rows into the changelog and roll forward any slipped dates with a note explaining why.
Ready-to-Paste Variations
Now / Next / Later roadmap
Avoids quarter commitments for uncertain work. Popular for public and open-source roadmaps where dates create pressure the team cannot control.
| Horizon | Initiative | Why it matters | Tracking |
| :---: | :--- | :--- | :--- |
| Now | Visual grid editor | Most-requested feature in user feedback | #212 |
| Now | CLI converter | Lets CI pipelines generate tables | #198 |
| Next | Column type inference | Fewer manual alignment fixes | #240 |
| Later | Real-time collaboration | Needs sync architecture decision first | #251 |Quarterly plan with confidence
Keeps dates but makes the uncertainty explicit, so readers weigh a Q1 date differently from a Q4 one.
| Initiative | Target | Confidence | Owner | Depends on |
| :--- | :---: | :---: | :--- | :--- |
| CLI converter v1 | Q4 2026 | High | Open Source Eng | — |
| Column type inference | Q1 2027 | Medium | ML team | CLI converter v1 |
| Collaborative editing | Q3 2027 | Low | Product Strategy | Sync service design |Common Mistakes
Leaving past quarters marked “In Progress” or “Planned”.
Every row whose target quarter has passed must be either shipped or re-dated with a note. Stale rows destroy trust in the whole page faster than a slipped date does.
Giving far-off work the same precision as next month’s work.
Use quarters for committed items and Now/Next/Later or a confidence column for the rest, so readers can tell a commitment from an aspiration.
Listing tasks instead of outcomes.
“Refactor sync module” is a task; “Edits appear for collaborators within a second” is an outcome. Roadmap rows should describe what users get, with tasks living in the tracker.
Too many status values.
Limit the legend to four or five states and use them consistently. If two rows show “⚡ In Progress” and “🔨 Building”, readers will assume they mean different things.
Related Markdown Table Templates
Browse all 50 templatesRisk Assessment & Mitigation Matrix
Identify potential technical and business risks, calculate probability and impact scores, and document mitigation strategies.
Company & Team Quarterly OKRs Matrix
Objectives & Key Results governance table tracking strategic focus, baseline metrics, quarterly goals, confidence ratings, and leads.
Agile Sprint Backlog & Task Board
Sprint planning task table with ticket IDs, user story descriptions, story points, priority ratings, assignees, and kanban status.
Project Roadmap & Milestones: Frequently Asked Questions
Should a public roadmap include dates?
Only when you are confident enough that missing them would surprise you. Many open-source projects use Now/Next/Later precisely because dates on volunteer-driven work become broken promises. Customer-facing roadmaps usually add a disclaimer that plans may change.
How is a roadmap different from a sprint backlog?
A roadmap covers quarters and describes outcomes; a sprint backlog covers one sprint and lists the specific items the team has pulled in to work on. Roadmap rows usually break down into many backlog items.
How often should the roadmap be updated?
Review it at least once a quarter, and update individual rows whenever a status changes in the tracker. A visible “Last updated” date tells readers how much to trust it.
What should happen to completed items?
Keep the most recent shipped items briefly for context, then move them into the changelog or release notes. A roadmap that is half history makes it hard to see what is actually coming next.