Baselines and Slippage in Jira: How to Record Your Plan and Track Where It Drifts

The plan you promised your stakeholders and the plan you actually have are two different documents. The gap between them is slippage — and in plain Jira, that gap is invisible, because the moment anyone moves a date, the "current plan" silently becomes the only truth. There is no longer any record of what was promised, so slippage can only be discovered by memory, or by a stakeholder who still has the old dates.

This guide explains how to make slippage a measured number: when to record a baseline, how to read drift task by task, how to tell a planning failure from an execution failure, and when it is professional to re-baseline — versus when re-baselining would simply erase the evidence.

What a baseline actually is

A baseline is not a screenshot of a Gantt chart. It is a contract: a professional snapshot of your schedule — start dates, finish dates, and work effort — captured at the moment of formal stakeholder approval.

That timing is the golden rule of project controls. A baseline recorded against a draft plan means you are measuring performance against a target nobody ever committed to. Record it once, after sign-off, and it becomes the yardstick for everything that follows.

Industry practice is consistent on the second rule as well: a baseline you re-record every week is not a baseline, it is a moving target with extra steps. Re-baselining is a governance event, not a maintenance task.

Why native Jira can't hold a baseline

Jira is built to track what is happening to a ticket — status, assignee, dates. It has no concept of what was promised:

• No baseline object. Jira stores the current due date. There is nowhere for the approved date to live once the current one moves.
• Silent rewrites. When a user edits a date, the plan's history is overwritten. The evidence of slippage — the delta between promise and reality — is deleted, not preserved.
• No variance. Without a stored commitment, "are we late?" has no mathematical answer. It becomes an opinion in a standup.

The result is the classic failure mode: projects that look "Green" because nothing in the tool records that they are no longer on the committed plan.

Record the baseline once, deliberately

Here's the practical workflow, using MSP Planner for Jira — a Forge-native app that adds a professional scheduling layer on top of your Jira data.

1. Capture the plan at sign-off

Once your schedule — dependencies, durations, resource assignments — is formally approved, save it as the baseline. The snapshot stores start dates, finish dates, and work effort for the whole schedule, so the commitment is complete, not just a set of milestone dates.

tip

Set the baseline immediately after sign-off, not "sometime this week." In project controls practice, the baseline is the legal/formal commitment — the later you record it, the more untracked drift you inherit before tracking even starts.

2. Work the live plan without touching the promise

After the baseline is captured, the team keeps working the live schedule in Jira as normal. Dates move, dependencies change, scope shifts — and the baseline stays exactly where it was: the approved commitment, untouched.

Read slippage task by task, not just at the finish line

A single project-level number — "we're 4 days late" — tells a steering committee nothing they can act on. Professional variance analysis is done per task, against the baseline.

3. Turn on the comparative overlay (ghost bars)

MSP Planner's Comparative Overlay loads your baseline schedule as the comparison target and merges its dates into your current view as thin, shaded ghost bars beneath your live tasks:

• The live bar — where the work is scheduled now.
• The baseline bar — where it was promised.

Read the relationship directly: a live bar sitting right of its ghost bar is negative drift (slippage); a bar sitting left is positive drift (acceleration). Any stakeholder can see the drift in seconds, without a spreadsheet — the same pattern Microsoft Project's Tracking Gantt view uses for baseline comparison.

4. Weight the slippage by criticality

Not all slippage is equal — and this is where a plain date comparison misleads. A five-day slip on a task with plenty of float may move the finish date by zero days, while a one-day slip on the critical path is a project-level event. Track slippage along the critical chain first: that is the slippage that actually drives your deadline. (See the Critical Path in Jira guide for how the chain is calculated.)

5. Separate planning failure from execution failure

This is the part most tools never give you. MSP Planner's triple-point analysis compares three lines at once — baseline, planned, and actuals (from posted Jira worklogs) — so you can isolate why the project is drifting:

Comparison	The question it answers	If it shows drift…
Baseline vs. Planned	Did we underestimate?	The original estimate was optimistic — a planning failure.
Planned vs. Actuals	Are we performing as planned?	The team is under-performing or blocked — an execution failure.
Baseline vs. Actuals	What is the real impact?	The total drift your stakeholders actually experience.

That distinction is what makes the status report honest. Instead of "the API integration is scheduled for October 15th," you can say: "The API integration has slipped 4 days against the approved baseline. We neutralized it by accelerating the frontend layout task — zero impact on the project finish date." Same facts, one report a steering committee can act on.

When to re-baseline — and when not to

Re-baselining is high-stakes. Done reflexively, it becomes "performance masking": resetting the clock so the delay stops showing. Done deliberately, it keeps reporting honest. The professional rule:

• Re-baseline on an approved change. Formal scope change, a change order, or a major external shift that genuinely alters the commitment. In MSP Planner this is the Materialize action: you select the new agreed state and bake its dates into the schedule as the new baseline — a deliberate, confirmed, destructive operation, not a background setting.
• Do not re-baseline on poor performance. If the team is simply behind, re-baselining deletes the problem. The professional response is a recovery schedule: keep the original baseline intact so the variance stays visible, and work a new plan that shows how the team intends to catch up.
• Keep the audit trail. Log why and when every baseline was set or changed. At the end of a phase, archive that baseline — it becomes historical performance data for estimating the next one.

tip

A useful PMO health check: if a large share of your tasks is showing negative drift at once, the problem is usually not the tasks — it is an over-optimistic resource plan or underestimated complexity. The baseline shows you that pattern; without it, you'd just be chasing individual slips.

A note on where your data lives

Baselines are some of the most sensitive data in a portfolio — they are the commitments your organization is held to. Many scheduling tools replicate your plan, dates, and people onto the vendor's own servers.

MSP Planner for Jira runs on Atlassian Forge, so it operates inside Atlassian's infrastructure — your baselines and planning data stay within the Atlassian environment and aren't copied to an external server. For orgs with data-residency or vendor-risk requirements, "runs on Atlassian" turns a procurement objection into a non-issue.

FAQ

Does Jira have a native baseline? No. Jira stores the current dates of an issue; when they change, the previous values are overwritten. There is no stored "approved plan" to compare against, which is exactly why slippage goes untracked. MSP Planner adds the baseline layer on top of your existing Jira issues.

When exactly should I record the baseline? Immediately after formal stakeholder sign-off — while the plan is still what you actually promised. Recording it earlier (against a draft) or later (after drift has already happened) both corrupt what the measurement means.

What's the difference between re-baselining and a recovery schedule? Re-baselining (Materialize) is for approved changes: new scope, new constraints — the commitment itself has changed, so the yardstick changes with it. A recovery schedule is for poor performance: the commitment stands, and you work a visible catch-up plan against the unchanged baseline.

How do I see slippage without opening a spreadsheet? Turn on the comparative overlay: the baseline appears as ghost bars under your live tasks, right-shift = slip, left-shift = acceleration. Combined with the critical path view, you can tell which slips actually move the deadline.

Do I need MS Project to do baselines properly? No — the same discipline works natively in Jira. If your PMO still reports in MS Project, the schedule (including baselines and dependencies) round-trips losslessly, so both tools show the same commitment.

Next step

If you can't currently answer "how far are we off the plan we promised?", the fastest fix is to record one real project's baseline at sign-off and read the ghost bars for a single week.

See how it works on the MSP Planner for Jira product page, read the baselines & variance documentation, or book a walkthrough.