Someone asks whether your team can take on a project in Q3. You open Jira. Jira shows you sprints, epics, a backlog — all of it work that already exists as tickets. The project you were asked about? Doesn’t exist. It’s a conversation, a slide, maybe a signed contract, but nothing has been scoped and nothing has been written down as a work item.
So you answer from memory. And you’re wrong often enough that people have started treating your answer as a rough mood rather than a number.
That gap is what resource forecasting actually is, and it’s the part Jira was never built for. Jira is a system of record for work that exists. Forecasting is about resource demand that hasn’t become tickets yet.
What Jira can’t tell you, and why
Let’s be fair to Jira. In the present tense it’s great. Velocity tells you what a team gets through, the board tells you what’s in flight, and project progress on anything already scoped is right there whenever anyone asks.
And while we’re untangling terms:
- resource planning is what you do with work you’ve already committed to,
- resource allocation is deciding who picks it up this week,
- and forecasting is the one looking at months nobody has committed to yet.
They feed each other in one direction only. Get the forecast wrong and you’ll optimize resource allocation beautifully inside a plan that was never going to work.
One more, since the terms collide in search results. Human resource forecasting is an HR exercise about headcount and hiring. This post is the project management version: whether the human resources you already have can absorb the future projects heading your way.
Now push the horizon out to a quarter, and four things go missing. These are the resource forecasting challenges that show up in every thread on this topic:
- Unticketed demand. Your upcoming projects have no epics, no stories, no estimates. Invisible to every report you own.
- Confidence. A signed contract and a “they seemed keen on the call” look identical in Jira. Which is to say, they both look like nothing.
- Team-level estimates. Early on nobody knows who’s doing the work. Jira’s planning tools want an assignee, so you put a name on something starting in four months and then maintain that fiction until it stops being funny.
- Future resource availability. Sprint capacity assumes everyone shows up. Three months out, leave, part-time schedules and people split across multiple projects are what decide your current resource capacity. Capacity planning in Jira will carry you through the next sprint or two, but not through a quarter.
- None of this is a bug. It’s what happens when you ask a tool that tracks work about work that doesn’t exist.
How to forecast resources, using the placeholder pattern
So here’s what project managers who forecast reasonably well in Jira actually do. One delivery lead summed it up: he couldn’t see a way to forecast time in Jira without tying it to something, so he made something to tie it to.
- Create a dedicated work type. Placeholder, Pipeline Item, pick your name. A Jira admin adds it to your work type scheme. That separate type is the whole trick — it’s what keeps these from ever being mistaken for real work. Everything below falls apart without it.
- One placeholder per project per team. Not per person. This is where people go wrong. You don’t know who’s doing it yet, and pretending you do gives you a plan that dies the first time somebody changes role. As that same lead put it, they estimate by team because the team doesn’t know enough yet to do it by individual. Honest, and it works.
- Estimate twice, deliberately. Rough numbers before discovery, tighter numbers after. Say out loud that the first one is a range. Do this and you stop having the argument about whether the early estimate was wrong — it was labelled early, that was the point.
- Dates are a window, not a schedule. July to September means “somewhere in here”. That’s enough to spot collisions, which is the entire job.
- Tag the confidence. A label or custom field with three values — committed, likely, speculative. Now one forecast is three. Filter to committed, that’s your floor. Include speculative, that’s your worst case. Congratulations, you’re doing scenario planning and you spent nothing. More to the point, you’ve turned a pile of maybes into a stated view of future resource needs that somebody else can argue with.
- Decide how placeholders die, before you make the first one. Either it gets replaced by real epics when the work is scoped, or it gets closed. Skip this and your forecast fills with ghosts inside two quarters. Ghosts are worse than no forecast, because people believe them.
- Keep them off delivery boards. issuetype != Placeholder in your board filters. Developers should never lay eyes on these. They’re a planning artifact, and the moment someone picks one up and tries to work it, you’re done.
Where the numbers come from: your own historical data
A placeholder is only as good as the estimate inside it, and “a number that feels about right” is how forecasts lose credibility. The most dependable of the common resource forecasting techniques is also the least exciting: go look at what similar past projects actually cost you.
Your historical project data is already in Jira. Roughly:
- Pull past projects of a similar shape. Same type of work, same ballpark size. Five or six is plenty.
- Take actual effort, not estimates. Logged hours if your team tracks time, elapsed calendar time per team if it doesn’t.
- Produce a range, not an average. “Integrations like this run 300 to 500 hours” beats 400 every time, because 400 invites someone to treat it as a promise.
- Look at what the outliers had in common. Spoiler: it’s the same thing every time. A dependency on another team, an unfamiliar system, or a client who changes their mind on a schedule you could set a watch by.
- Size the new placeholder off that range, and put the comparison in the ticket description so the next person can check your reasoning instead of re-litigating it.
That’s the resource forecasting process in five steps, and the unglamorous truth is that effective resource forecasting is mostly this, repeated. Historical data analysis is the only thing that makes accurate resource forecasting get better over time. Every delivered project is another data point and the ranges tighten. Skip it and you’re forecasting on instinct forever, which is fine right up until someone asks why the last three quarters ran over.
What past project data won’t give you is market trends or shifts in project priorities — a new product line, a reorg, a client segment going cold. That comes from the people running the business, not from Jira. Which is why the forecast has to be a conversation and not a report you email out and hope someone reads.
Reading demand against supply
Once the placeholders exist, you can finally do the thing you wanted: put future demand next to available capacity and look at them together, instead of holding one in your head while you read the other off a screen.
A department head I spoke with wanted exactly this — a pipeline view of now, next, and later with the resource profile sitting underneath it, so the capacity problems turn up on the same screen as the strategy. If the pipeline part is what you’re missing, building a cross-project roadmap is the half of this that native Jira handles better than people expect.
Another was blunter about why it matters: he wanted to know whether internal capacity matches what the sales side keeps selling.
That’s the question worth answering. Not “what was our resource utilization last quarter” — that’s history. The one that matters is: if we say yes to this, what breaks?
Natively, you can get part of the way with a saved filter over your placeholders plus Original Estimate, read through a Workload Pie Chart gadget grouped by team. It works, and for one team, it’s often enough. It’s also a static number with no dates in it, so it’ll cheerfully tell you the quarter is over capacity without mentioning which month. That month, of course, is the one everyone ends up arguing about.
When Jira plus placeholders stops being enough
This pattern carries a lot of teams a long way. It starts to creak in three places:
- Several teams and a real project pipeline. Past a handful of teams the saved filters multiply, and nobody maintains them. Nobody ever maintains them.
- People split across multiple projects. Jira has no native view of one person’s total commitment across everything, and that’s the number that decides whether a plan is real.
- Billable work. Professional services firms need the forecast tied to revenue and margin, which is a different category of tool entirely.
That last one deserves straight talk. If your forecast has to answer financial questions, a project management tool won’t get you there — you’re looking at professional services automation, or dedicated resource forecasting software, where the forecast lives next door to billing. Most resource forecasting tools split along exactly this line, and knowing which side you’re on saves you three demos.
If it only has to answer delivery questions, resource management software that reads your Jira data is the shorter route, because the data is already sitting there and nobody has to type it in twice. Which of the best resource management tools fits comes down to which of those two problems you have. Worth knowing before somebody starts a trial on a Friday afternoon.
Where a resource management tool can help
Here’s where I’m biased, so weigh it accordingly.
The placeholder pattern wants a resource management platform on top for one reason: a placeholder is only useful sitting next to real work and real availability.
Planyway for Jira puts both on one timeline, so your forecast gets checked against the same capacity numbers your live sprints are checked against.
- Capacity is per person and rolls up to the team. Someone on a 30-hour week counts as 30. Team capacity is the sum of real schedules, not headcount × 40 — which is the number most forecasts assume without ever admitting it.
- Future absences come off by themselves. Holiday schemes per country, vacations on the timeline. A forecast that counts August at full strength isn’t a forecast, it’s a wish.
- Grouping by team. Placeholders assigned to a team rather than a person still land in the right row, so a forecast made at team level stays readable at team level.
- Placeholders sit beside committed work. You see the month where a pipeline item overlaps two live projects. That collision is the whole reason you did any of this.
➡️ Try Planyway free
For revenue attached to the forecast, see the paragraph above.
Free for teams up to 10, if you’d rather try the pattern before committing to anything.
What forecasting still won’t fix
- It won’t make bad estimates good. A placeholder with a made-up number is a made-up forecast in nicer formatting.
- It won’t survive without an owner. Somebody keeps the pipeline list honest, or it rots inside a quarter.
- It won’t settle a resource conflict. It makes the conflict visible early enough that somebody can decide — different thing, and usually enough.
- It won’t replace the conversation with whoever’s selling the work. It just gives that conversation numbers.
Over to you
- Anyone here forecasting in Jira with placeholder work items? What type did you use, and did it stay clean?
- If you forecast somewhere else — spreadsheet, PSA tool — what made you give up on doing it in Jira?
- For teams running across several projects: how far out does your forecast stay useful before you stop trusting it?
