Software Project Roadmap Template: Milestones and Estimates

October 14, 2026 · 8 min read

A software project roadmap at the end of discovery is a table of milestones, each with a start date, a target date, an effort range, the milestone it depends on and the requirements it delivers, plus a short list of the assumptions behind it. It answers "what gets built in what order, and roughly how long will it take". Below is the table to copy, how to find the critical path, and a filled-in example with a month-scale timeline.

Discovery roadmap vs product roadmap

The word "roadmap" covers two different documents, and mixing them up causes trouble.

A discovery roadmap is concrete on purpose. Each milestone should be traceable to requirements, so that when someone asks "why is this taking ten weeks?" the answer is a list of things, not a feeling. It is closer to a delivery plan than to a vision deck. If the project later becomes a long-lived product, a product roadmap can sit above it; the discovery roadmap covers the first release or two.

The milestone table

Use one row per milestone. Seven columns are enough:

Add a status column (Not started, On track, At risk, Done) once the build starts, and keep a separate list of assumptions next to the table: team size, the date a vendor delivers an API key, a holiday freeze, who tests. Assumptions are what the dates rest on, so they belong on the same page.

Two checks catch most gaps in a draft:

1. Coverage. Count the requirements linked to at least one milestone against all requirements. Anything unlinked is either out of scope (say so) or missing from the plan.
2. Size. If one milestone holds most of the effort, split it. Milestones in the range of two to six weeks are easier to track than one of five months; that is a rule of thumb, not a standard.

The roadmap section of our discovery phase template sums up the same contents in four lines:

Dependencies and the critical path

A dependency says one milestone cannot start until another is done. The chain of dependent milestones with the longest total duration is the critical path: any delay on it delays the release, while a delay elsewhere may not. The idea comes from the critical path method, used in project scheduling since the 1950s.

To find it on a small roadmap:

1. Write each milestone's dependency.
2. Follow each chain from the first milestone to the release.
3. Add up the durations along each chain. The longest is the critical path.

Watch for two warning signs. A milestone that starts before the one it depends on ends is either a mistake or a sign the dependency is partial and should be split. A cycle (M3 depends on M4, which depends on M3) means the work is not really sequenced at all. In software projects, the critical path very often runs through integrations and data migration, because they depend on people outside the team.

Estimates as ranges

Put a low and a high figure on every milestone, in person-weeks, and add them up for the total. A single number at this stage hides how much is still unknown. Steve McConnell's "cone of uncertainty" describes estimate error that narrows as a project's decisions get made (Construx); at the end of discovery the range is narrower than at the first conversation, but it is still a range.

Practical habits:

• Tighter near, looser far. The first milestone, which the team understands best, can have a narrow range; later ones wider.
• Effort is not duration. Six person-weeks with three people may be two calendar weeks, or four if they are also on other work. Dates come from effort plus staffing plus the assumptions.
• Sum the lows and the highs separately. Report the total as "34–46 person-weeks", not as the midpoint.

A filled-in example (invented)

An invented project: a mobile inspection app for a utilities company, with requirements numbered REQ-1 to REQ-24. Team assumption: three developers and one designer, with a two-week holiday freeze in late December.

Total: 38–55 person-weeks, target release April 10. M5 waits for two milestones here, which breaks the "one dependency" rule of thumb on purpose: the pilot needs both the integration and the reports. On a real plan you might split M5 so each part has a single predecessor.

The same plan on a month scale (each column is half a month):

            Nov     Dec     Jan     Feb     Mar     Apr
M1          ##
M2              ####    ##
M3                      ####
M4                          ##  ##
M5                                  ##  ##
                                            ^ release Apr 10

The critical path is M1, M2, M4, M5: the forms are the longest chain, and the holiday freeze sits inside M2. The billing integration (M3) has some slack, unless the billing system owner is slow to provide test access, which goes on the assumptions list.

Keeping the roadmap honest

A roadmap stays useful only if it is updated when the facts change:

• Change a status by hand when the team knows, not when a date passes. "At risk" two weeks before a target is information; "late" afterwards is history.
• Re-check the dependencies when scope changes. A new requirement linked to M2 moves everything on the critical path.
• Review the assumptions at each milestone. If the team is two developers, not three, the dates move, and that is a decision to make openly.
• Keep the link to requirements. When a requirement is dropped, remove it from its milestone and reduce the estimate, so the plan shrinks with the scope.

Here is how a finished roadmap reads in our example report, made for an invented project called Fieldwise: the total estimate as a range, the release date, a month-scale timeline, the milestone table with status and linked requirement counts, and the assumptions underneath.

In Discovery Phase AI, the roadmap stage holds the same fields: milestones with an ID, dates, a low–high person-week estimate, status, one dependency and linked requirements, a month-scale timeline, and a list of assumptions.