There’s an old thread in this forum where someone asks it better than I could:
“It feels like a hack to add an Epic or a Story for a vacation. Is there another way to account for time off / PTO / Vacation / Holiday?”
Five years on, the answer hasn’t really changed. There is still no native absence management in Jira: no days off, no non-working days, no real time visibility into team availability. So you either make a ticket for someone’s holiday and feel a bit silly about it, or you keep it in your head and hope.
Here’s what teams actually do, roughly in the order people try them.
Where can I input days off for team members in Jira?
Nowhere. Short answer, worth saying plainly, because people lose an afternoon hunting for the setting.
Jira knows dates on a work item, what’s in a sprint, what’s been logged. It doesn’t know working hours, part-time arrangements, public holidays, or that anyone’s away.
The native timeline won’t even let you hide weekends, which tells you how much thought went into non-working days.
So all of this is something teams build themselves.
Workaround 1: dummy tasks for vacations
The one everybody tries first, and the one people call a hack themselves.
Create an issue type — usually something like Admin and annual leave — and raise a ticket whenever someone’s off. One team here described keeping a whole epic for it, where each person adds a task per period of employee time off, with the hours they won’t be available and a due date for when they’re back. It’s time off management built out of the only material Jira gives you: work items.
The logic holds up: if an absence is a work item with dates, it shows on the board, on the timeline, and in anything counting assigned work.
What it costs you:
- The backlog fills with tickets nobody will ever work on, and they show up in filters, reports and sometimes velocity.
- Somebody has to remember to create them. Unplanned leave never gets a ticket in advance — nobody files a sick leave ticket the night before.
- Employee leave data now sits where anyone with project access can read it. Fine for “out of office”, less fine when someone types the reason into the summary. If you’re in the European Union, that’s worth a thought before you roll it out rather than after.
Workaround 2: override the sprint velocity
The tidier one, and where people go after the dummy tasks start annoying them. On Plans you can override the default velocity for a specific sprint instead of making tickets. So, instead of creating dummy tasks, you just reduce the capacity available for that sprint.
Better. Still not great. The number changes and the reason vanishes. Two sprints later nobody remembers why that fortnight was light, and the chart reads it as a slow sprint rather than a short-staffed one. It’s also per team, not per person — so it tells you the team has less capacity without telling you the one person who can do the migration is the one on holiday.
Workaround 3: a spreadsheet with macros
Not a joke. Someone here described exactly that: a spreadsheet with macros working out team capacity per sprint by recording the common public holidays and everyone’s planned vacation days.
It works, and it saves time compared with doing the sums fresh each fortnight. It’s also a second system that one person understands, and it’s wrong the moment somebody’s plans change. Manual processes always are — that’s human error, not carelessness. Fewer mistakes is most of the argument for getting this out of a spreadsheet at all.
Workaround 4: some kind of a team calendar (but there's a catch)
HR has the approved leave. The team has a shared calendar. Jira has the plan. All three are right, none of them talk, and sprint planning turns into opening a second window and hoping it’s current.
Atlassian themselves described the ideal in a reply on this forum: you shouldn’t have to set absences in several places — wherever you log them in your organisation, they ought to flow through to your plans. That’s exactly what’s missing, and it’s been a known gap for years.
Workaround 5: marketplace app
This one isn’t exactly a workaround, since it’s the only option here that treats an absence as an absence. So, what these apps do is they hold availability per person. Working hours, holiday schemes, vacations and days off as their own objects — so the capacity maths accounts for who’s away without anyone creating a work item nobody will ever do.
Shameless plug: Planyway for Jira is one of those time off management apps.
In Planyway, you can set up:
- Individual working hours (like part-time schedules and such);
- A holiday scheme picked by country;
- Plus, vacation time and days off marked straight on the timeline.
All of it comes off their available capacity automatically, so the workload view shows who’s genuinely free instead of a theoretical 40-hour week.
Looks like this:
➡️ Try Planyway free
What it costs when Jira doesn’t know who’s away
You commit to sprints nobody could have delivered. The board adds up to 200 hours. Forty of them are sitting on a beach. Nobody spots it until the sprint review, when the math finally gets explained out loud.
Work slips and nobody can say why. A ticket sits untouched for a week because the one person who could pick it up is away. Jira says nothing about that, so nobody chases it, and a week later you’re the one explaining the delay.
You can’t answer the question you get asked most. “Do we have enough people for next sprint?” You either know who’s off for the next three weeks, or you’re guessing. Most of the time it’s guessing, and everyone in the room knows it.
August and December keep catching you out. Same two months every year. Half the team disappears, delivery falls apart, and somehow it’s still a surprise in January.
This isn’t HR leave management, and the difference matters
Two problems get mixed up constantly. Worth pulling apart.
An HR leave management system is about entitlement and legal compliance: PTO balances, PTO accruals, remaining balances, personal days, parental leave, medical leave, sick time, jury duty, unpaid/paid time — all the leave policies that follow from national laws and local labor regulations. It needs a way for employees to request time off, for managers to approve requests and manage employee time, and for all of it to land in HR records that feed payroll systems. The good ones do it through employee self-service: self service portals with mobile access where people file PTO requests from a phone instead of paper forms, with PTO categories, fair approvals and accurate records that stand up to legal requirements. In the EU especially that’s a conversation for HR professionals and legal counsel, not a Jira admin.
No Jira app replaces that. If you’re managing PTO as an entitlement, you want proper PTO tracking software and an HR department owning it.
And the business case for one isn’t a planning case. Leave management systems get bought to cut manual work around recording leave requests, reduce compliance risks, and — the arguments that actually land upstairs — to support employee satisfaction, employee morale and work-life balance by making time off easy to take. All real. None of it tells you whether next sprint is achievable.
Planning is the other problem: given that Marta has approved leave next week, does the plan still hold? That needs far less — a date range, a person, and for the capacity maths to account for it. No balances, no approval workflow, no doctor’s note.
Most teams need both, from different systems. HR owns entitlement and approvals; the dates flow into wherever you plan. One source for “can I take this”, another for “can we still ship this”. A tool that ticks all the boxes for HR teams usually ticks none of the ones for workforce planning, and that’s fine — they’re different jobs.
What to do if you’re stuck with the workarounds
Pick one place absences live and tell everyone. Most of the mess comes from three half-correct lists.
Get them in front of whoever runs sprint planning. However it happens — a Friday reminder in Slack, a calendar on the second screen — the person committing to the sprint needs to know who’s out beforehand, not after. Absence management only pays off at the moment someone’s about to promise something.
Treat public holidays as a planning input. They’re known a year ahead. If your team spans countries, that’s several calendars, and pretending otherwise just moves the surprise to a Monday morning.
Leave room for unplanned leave. People get ill. A team planned to 100% of theoretical capacity has no room for an ordinary week with flu in it.
If you’re using dummy tasks, filter them out. Exclude that issue type from your board filter and reports so it isn’t quietly bending your delivery numbers.
Over to you
How are you handling this — dummy tasks, a velocity override, a spreadsheet, or something smarter?
And for anyone with people across several countries: what are you doing about the different public holiday calendars?
