One Person, Two Projects in Jira: How to Split, View, and Protect a Shared Resource
The same senior engineer is 100% on Project A's board and 100% on Project B's board. Mathematically that's 200% — and both dashboards say Green.
Splitting a person across projects is completely normal in any matrix organization. What's abnormal is a tool model that can't admit it: in native Jira, an assignment is binary (a person is on an issue or not) and per-issue (it says nothing about how much of that person's week it claims, or for which weeks). So the split lives in the PM's head and a spreadsheet — and the collision surfaces at execution, not at planning.
This guide is the practical answer to "how do I get a resource working on two projects and still see it in Jira": how to express the split, how to see one person's total load across all projects, how to catch over-allocation before it slips a deadline, and how to fix it deliberately.
Why native Jira can't express a split
- Assignment is binary and instantaneous. A Jira assignee is either on an issue or not — no percentage, no date range, no "50% from March to April."
- There is no cross-project total. Each board shows its own assignments. Nobody's view shows that the person is 120% in aggregate.
- Capacity is assumed, not modeled. Jira has no notion of available working time — part-time patterns, holidays, approved time off — so even a correct allocation has nothing to be compared against.
The result is the classic "siloed collision": each PM is planning honestly, the person is genuinely committed to both projects, and the overload is only discovered when the work doesn't get done.
Express the split: partial allocation
Professional PMOs don't assign people to projects — they allocate portions of capacity over time. The standard vocabulary:
- Percentage-based allocation — 50% to Project A, 30% to Project B, 20% to run-and-maintain. The person is one resource; the numbers are the plan.
- The resource allocation matrix — rows are people, columns are projects, cells are percentages. It is the fundamental planning artifact for any portfolio, and the "one person, two projects" question is literally one row of it.
- Skill-based and role-based splits — a Lead architect reviews across five projects at 10% each; or you book "a senior developer" for a window and name the person later. Both are allocation, just at a different level of detail.
Here's how that works in practice, using Resource Management for Jira — a Forge-native app that adds the allocation layer directly inside Jira.
1. Raise the split as a resource request
The Project Manager raises a resource request: a role or person, an allocation, over a date range. The allocation isn't a text note — it's a number, and it's measured in the same units as the person's real availability, so "50% in March" means something verifiable instead of something hoped for.
2. The Team Manager validates against real capacity
The Team Manager reviews the request with the resource's effective and remaining capacity in front of them — calculated with one-minute precision from working calendars, approved time off, and hours already committed to other projects. That last term is what makes the cross-project case work: the capacity view already knows this person is 50% on Project A, so the second ask is measured against what's left, not against a fresh 100%.
The interactive planning view is built for exactly this: the Team Manager can drag an assignment onto the timeline, set the allocation, and watch the remaining capacity update instantly — the literal answer to "if I give Sarah 50% to this project, who else on the team becomes overloaded?"
Allocations can deliberately exceed 100% for short windows — the tool's allocation scale runs to 250%. The point of showing it is not to forbid it, but to make a 130% week a visible, deliberate decision instead of a spreadsheet accident.
3. Accept partial — and track the gap
If the team can only give 60% of what was asked, the request is accepted partially, and the gap is tracked as a number. That difference between "what the project needs" and "what it got" is a leading indicator of slippage — and it's now visible before the work starts, not after.
4. Turn the accepted allocation into real Jira work
On acceptance, the corresponding Jira task is created with the right assignee and watchers, so the board and the plan can't drift apart. The allocation stays the commitment; the issues stay the execution.
See total load in one view
The "in Jira view" part of the question deserves its own answer, because per-board views are structurally blind to it.
- Per person, across projects. The capacity view for a resource includes cross-project load — hours already committed to parallel projects — so one row shows the whole picture: this person, all projects, one timeline.
- Per team, across projects. Analytics puts capacity, requested allocation, filled allocation, and actuals on the same timeline (day, week, month, or quarter), filterable by project, team, member, or role — Team mode answers "can my teams absorb incoming demand?", Project mode answers "is this project getting the capacity it asked for?"
- The overload signal. With those series side by side, a person who is 120% in aggregate is not a mystery — it's a row where demand exceeds capacity for a visible number of weeks.
The industry rule of thumb for reading those numbers: green ≈ 70–85% of capacity is healthy (the buffer is deliberate — it absorbs meetings, admin, and the unexpected); 85–100% is near capacity; over 100% is over-allocation. And if a person's actual logged time runs consistently around 120% of plan, that's not a bad week — it's a structural over-allocation that no amount of heroism fixes.
Fix it deliberately: leveling vs smoothing
Once an overload is visible, the fix is a decision — and professional practice distinguishes two of them:
| Resource leveling | Resource smoothing | |
|---|---|---|
| Goal | Resolve the conflict — nobody exceeds capacity | Even out peaks and valleys |
| Impact on the finish date | Usually moves it — that's the honest trade | Does not change it — uses float |
| When to use | Resources are hard limits that cannot be exceeded | You have the people; you want to avoid burnout |
| Typical moves | Split the task, delay its start, reassign to a qualified person | Shift non-critical work into periods of lower load |
The decision about who gets the contested hours should come from your portfolio priority list — which project outranks which — not from who asked first. And the review cadence matters: allocation is dynamic, so professional PMOs revisit it weekly or bi-weekly, not once per quarter.
A note on where your data lives
Cross-project allocation data — who works where, how much, at what rate — is exactly the kind of workforce data a security review scrutinizes. Many resource tools move all of it to the vendor's own servers.
Resource Management for Jira runs on Atlassian Forge, so it operates inside Atlassian's infrastructure — your allocation and capacity data stays within the Atlassian environment and isn't copied to an external server. For organizations with data-residency or vendor-risk requirements, "runs on Atlassian" turns a procurement objection into a non-issue.
FAQ
Can one Jira user work on two projects at once? In native Jira, assignments are binary per issue — there's no way to say "50% of this person, March to April." Resource Management adds that: percentage allocations over date ranges, per person, across projects.
How do I see one person's total load across all their projects? The capacity view includes cross-project load — hours already committed to parallel projects — and Analytics compares capacity, requested, filled, and actuals on one timeline at day/week/month/quarter, filterable per person or team.
What does "over-allocated" actually mean in numbers? Allocations summing beyond available capacity. As a reading: 70–85% is healthy, 85–100% is near capacity, above 100% is over-allocated — and actual logged time persistently around 120% of plan indicates structural over-allocation.
If I level a conflict, does the project get late? Leveling usually moves the finish date — that's the honest trade of protecting the resource. Smoothing uses float to even the load without changing the finish date. Choose based on whether the date or the person is the hard constraint.
Do I have to copy or rename the person for each project? No. It's one resource identity everywhere; allocations from different projects reference the same person, which is what makes the total-load view possible in the first place.
Next step
If a person on your team is currently "100% on two boards," the fastest way to feel the difference is to raise their two commitments as resource requests and watch the total load resolve into one visible number.
See how it works on the Resource Management for Jira product page, read the resource requests documentation, or book a walkthrough.