What is a "ghost resource" in sprint planning?

A team member a sprint board still treats as available, because their time off exists only in a separate system — a personal calendar, an HR tool, a Slack status — that wasn't checked during planning. The person isn't a no-show; the plan was built on stale information from the start.

Doesn't a shared team calendar already solve this?

It solves visibility for whoever remembers to open it. It doesn't solve the planning moment itself, because the calendar and the sprint board are two different screens — an assignment gets made in Jira with no signal, in that same view, that the assignee is unavailable. The fix isn't a better calendar; it's putting availability where the assignment decision actually happens.

Does OutSync replace my team's calendar?

No — it complements it. OutSync's "who's out" panel lives directly on the Jira board and Confluence space so assignment decisions have availability data on-screen; the optional Google Calendar sync keeps a shared calendar updated automatically for anyone who wants that view too, so neither system goes stale relative to the other.

The Ghost Resource Problem: Why Sprints Plan Around People Who Are Out

Monday’s plan is already wrong

Sprint planning happens Monday morning. Eight stories get pulled in, split across the team, estimated, committed. One of them — a critical-path piece the rest of the sprint depends on — goes to a senior engineer who, as far as the board is concerned, is available all ten working days.

She isn’t. She booked Wednesday through Friday off three weeks ago. It’s in her personal Google Calendar, correctly, the way she was told to record it. It is not in Jira, because nothing in the sprint-planning process ever asks Jira to check.

Nobody lied. Nobody forgot to mention it in standup, because standup for that day hasn’t happened yet. The plan was simply built from incomplete information, and the team finds out mid-sprint — not because someone made a mistake, but because the tool making the assignment decision and the tool holding the availability data have never spoken to each other.

The term, and where it comes from

This exact failure mode has a name in the Atlassian ecosystem: a ghost resource — a team member the plan still counts as available because their time off lives somewhere the planning tool never looks. The phrasing comes from a March 2026 Atlassian Community post by Planyway (a Jira capacity-planning app), which puts it plainly:

“This is the ghost-resource problem. You make assignment decisions in Jira, but availability lives in Google Calendar, an HR dashboard, a messenger status, or someone’s memory.” — Planyway, Atlassian Community

The same post makes the sharper point underneath the naming: “Tracking vacations doesn’t prevent double-booking. Seeing vacations on the same screen where you assign tasks does.” That’s worth sitting with, because it’s easy to hear “ghost resource” and reach for a better calendar. A better calendar doesn’t fix this. The problem was never that the vacation wasn’t recorded — it’s that recording it and assigning work happen in two different places, and nothing forces the second to check the first.

Why “just use a shared calendar” doesn’t hold up

Teams reach for a few standard fixes, and it’s worth being specific about why each one is a patch on the symptom rather than the cause:

A shared team calendar. Now everyone can check it. Whether anyone does, at the exact moment a task gets assigned, depends on habit — and the failure mode above happens precisely because nobody thought to look. The calendar isn’t wrong; it’s just not where the decision gets made.

A Jira “Vacation” or “PTO” issue type. This is a workaround, not a fix, and it has its own well-known cost: it clutters the backlog with non-work items, skews velocity and burndown reports with entries that were never meant to be measured as work, and still doesn’t actually change sprint capacity — the sprint plans as if the full team is available, because a ticket sitting in the backlog doesn’t subtract days from anyone’s capacity calculation.

A capacity-planning add-on with its own separate view. Better than nothing, but it reintroduces the exact problem it’s meant to solve one layer down: now there are three places to check (Jira, the calendar, the capacity tool) instead of two, and the assignment still happens in Jira regardless of what any of the other two say.

The common thread: every one of these treats the fix as “make the information available somewhere,” when the actual requirement is “make the information available in the view where the assignment gets made, automatically, with no separate step to remember.”

The same gap, from the other direction

The ghost-resource problem is what happens when availability data is missing from planning. The mirror-image failure — reviewing real Marketplace feedback on the existing Jira leave- tracking apps turns up the same root cause from the opposite side: these tools solve leave tracking well, and stop there. A few concrete examples, pulled directly from public Marketplace reviews on real competing apps in this category:

One 2-star review of Leave Tracker reads: “doesn’t allow admins to input vacations/sick days for their team members” — an HR-administration gap, but also a planning gap: if an admin can’t log a known absence on someone else’s behalf, that absence has no path into the system at all until the person does it themselves.
A 2-star review of UpRaise Employee Garrison complains that its rounding to the nearest 0.5 day “makes zero sense” for partial-day leave — a rigid accrual model that doesn’t match how teams actually plan half-days around meetings and appointments.
Vacation Manager for Jira’s own reviews ask, across multiple years, “will there be a cloud version?” — a leave tracker that predates the planning surface it’s supposed to feed data into.

None of these are OutSync’s own claims about competitors — they’re what real users of those apps say, in public, about the specific gap they hit. The pattern across all three: leave tracking as a standalone record-keeping function, built and reviewed on its own terms, with no particular reason to also show up on a sprint board.

Tool fragmentation isn’t a leave-specific problem — it’s the default

It’s also worth being honest that this isn’t unique to vacation data. Asana’s Anatomy of Work index, a survey of 9,615 knowledge workers, found the average worker touches 10 different apps a day to get through routine work. Leave/availability data ending up in yet another disconnected tool isn’t a special case — it’s the default outcome of how most software gets adopted piecemeal across a growing team. The fix that actually works for ghost resources is the same fix that works for tool fragmentation generally: stop adding a new place to check, and put the data inside the tool where the decision already happens.

What actually closes the loop

OutSync’s “who’s out” panel is a board action on the Jira board itself and a Team Availability tab on the Confluence space — not a separate app, not a second tab to remember, not a calendar someone has to think to open. It shows who’s out today, over the next two weeks, or the next month, in the same screen where a sprint gets planned or a page gets assigned. An employee requests leave, an approver decides it from a queue scoped to their own teams, and the moment it’s approved, it’s visible right there — no export, no manual sync, no second system that can drift out of date.

For teams that also want a calendar view, an optional Google Calendar sync creates and maintains one shared calendar per team automatically, so approved leave appears on it (and disappears if later cancelled) without anyone re-entering it by hand. That calendar is a convenience layered on top of the board-level visibility — not a replacement for it, and not the only place the data lives.

The point isn’t “OutSync has a calendar too.” It’s that the availability data lives in the one place a ghost resource can’t survive: the same screen where the assignment gets made.