The project timeline went up on the wall in week one. Four phases, eleven milestones, a clean diagonal of bars ending on 14 November. The team had argued over every bar, sequenced the risky work early, and voted a four out of five on the date. It was a good plan.

By week six, three stories had joined the payments epic, the identity team had moved its API change to their next release, and one of two backend engineers was on leave. The timeline on the wall still ended on 14 November. Nobody had misreported anything. Nobody had redrawn it either.

A project timeline is accurate about the plan on the day it was drawn. The committed date has to be accurate about the plan the team has today.

What a project timeline is good at

A project timeline is a chronological view of the work: tasks or epics as bars, milestones as markers, dependencies as the order the bars sit in, and an end date at the right-hand edge. Gantt charts, swimlane roadmaps and phase diagrams are all project timelines in different clothes.

Building one is real engineering work. The team decides what goes first, which risks to pull forward, where hand-offs sit, and how much room each phase needs. That is expert judgment, and it is exactly what the team is voting on when it commits to the date. The timeline makes the plan legible to everyone who was not in the room.

What the timeline cannot show after the vote

A timeline is a drawing. It shows one sequence and one end date, and it changes only when someone edits it. The drift after the vote comes from the three things that erode a committed release date:

• Scope creep adds bars. Stories join an epic one at a time. Each one is small, so nobody stretches the bar. Added together, they are weeks.
• Late dependencies re-sequence them. Another team’s deliverable slips, or a review nobody planned for appears in front of testing. The timeline still shows the old order.
• Capacity changes stretch them. Leave, incidents and reassignments slow a phase down. The bar stays the same length on the wall.

There is a quieter problem as well. A timeline shows a single end date with no spread around it. Did the team mean “this is the date if most things go right” or “we are 85% sure”? The milestone chart has the same gap: it shows where the date was placed, not how likely it is to hold. A PERT chart puts a probability on the finish, but only once, on planning day.

Keep the timeline. Make the date live.

The fix is not to redraw the timeline every morning. It is to separate the picture from the number. The timeline stays as the team’s shared picture of sequence and intent. The end date gets a forecast that reads live Jira state: what is in scope now, which issue links are blocking, and how fast the team actually delivers. Re-run it whenever those change, and give it a confidence band instead of a single point.

An illustration: the team commits to 14 November at 85% confidence. In week six, the three new stories, the identity team’s slip and the reduced capacity move the 85% forecast to 1 December. The gap is seventeen days, and it is visible in week six, not in week twelve. The conversation becomes “which stories come out, can identity bring the API forward, or do we renegotiate the date?” while every option is still open.

How Advanced Release Planning keeps it live

Advanced Release Planning for Jira does not replace the team’s timeline or its judgment. The team owns the assumptions: which throughput window to trust, whose capacity is in, what is in scope, which links are real blockers. The app runs a Monte Carlo forecast over the team’s real Jira throughput, at a scale nobody runs by hand, and keeps it current.

• The committed date carries a live confidence band: 50%, 85% and 95%.
• Hard links drive a Critical Path view of the work currently dictating the date, including blockers in another team’s Fix Version. Soft links are recorded but do not drive the path.
• When scope, dependencies or capacity change, the movement is reported against the committed date in days.

For how dependency links feed the forecast, see the PERT Charts & the Committed Release Date reference in the product docs.

The project timeline records what the team planned. The forecast shows what that plan costs today, in days. With both, the team renegotiates before the date slips, not after.

FAQ

How do you create a project timeline?

Define the scope and deliverables, break them into work items, size each one, map which items wait on which, place milestones, and set the end date with the team. In Jira, that usually means epics and stories in a Fix Version, with issue links for the dependencies.

What is the difference between a project timeline and a project schedule?

The terms are often used interchangeably. A project schedule usually carries more detail (durations, owners, resources); a project timeline is the visual, chronological view of it. Both show a single end date unless a confidence level is added.

See your committed date and its live confidence band in Advanced Release Planning, or view it on the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio