Jira cannot see people
Jira tracks tickets, statuses and sprints. A production plan needs a roster with dates, capacity per discipline, and dependencies that move dates. Jira has no fields for those. This guide lists what is missing, what Jira Plans covers, and how a planner and Jira can work together without a sync.
What Jira is for
Jira answers questions about the current sprint: what is in progress, what is blocked, who is working on which ticket, what was closed. Teams should keep using it for that. This guide is not about replacing Jira.
The problem is a different question: will we make it with these people? That question needs three kinds of data Jira does not store.
Three things Jira has no field for
1. A roster with dates
Jira stores an assignee per ticket: one person, now. It does not store that the studio has three artists, that a fourth starts in November, that a programmer leaves in March, or that the outsourcing team is on the project for two milestones only. Capacity is people with a first day and a last day, per discipline. Jira has a list of accounts.
So the question “how many artists are we short in March?” cannot be answered from Jira. The data is not there.
2. Person-days per discipline per day
Story points measure a team's velocity against its own past sprints. They are not person-days, they are not attached to a discipline, and they are not on a calendar. A nine-month plan across art, code, design, audio and QA needs load per discipline for every working day, against the number of people of that discipline on that day. Adding custom fields to tickets to carry this produces a spreadsheet inside Jira, with the same problems as the one outside it.
3. Dependencies that move dates, gates, and variants
A blocks link in Jira records that two tickets are related. It does not move dates: if one ticket slips two weeks, the tickets behind it keep their dates, and nothing reports that the gate they were supposed to clear is now crossed.
Jira also has no variants. To answer “what if we cut feature X, hire two people and move the gate?” you need a second copy of the plan, and then two copies to keep in sync.
What Jira Plans (Advanced Roadmaps) covers
Jira Plans models team capacity in points per sprint, draws dependencies across boards, and shows a roadmap. For an organisation that runs scrum teams with stable membership, this is the right tool.
For a production studio it is missing the same things: capacity is per team per sprint, not per person per day; there is no roster with start and end dates; a gate is a date on a bar, not a rule a dependency can break; a “what if” is a second plan. And the plan lives in the Atlassian cloud, under the account. If those limits are fine for you, use Plans.
The spreadsheet next to Jira
This is where most producers actually plan. The spreadsheet has rows for people and columns for weeks, which Jira does not. It breaks for three reasons: no dependencies, so moving one cell moves nothing else; a roster that is a number per row rather than people with dates; and several copies with different numbers.
Two tools, two one-way roads
- The tracker holds the present. Tickets, statuses, this sprint. The team works there.
- The planner holds the future. Phases, gates, the roster with dates, demand against capacity per discipline, variants of the plan. The producer works there.
Between them, two one-way transfers:
- Plan → tracker. When a milestone is agreed, export its tasks as tickets: a CSV that Jira's importer reads, with epics for phases, stories for tasks, dates, estimates and blocks links. This is a one-time publication of the plan, not a sync.
- Tracker → plan. When you want to compare reality with the plan, run a JQL query and import the result as a board next to the planned one. This is a report, not a merge.
No two-way sync, because two systems that write each other drift, and the drift is invisible until a meeting. A transfer you run yourself, in one direction, at a time you choose, is easier to trust.
How Capaxima does it
Capaxima is the planner in that split. The roster holds people with start and end dates. A line under the Gantt shows demand against capacity per discipline per day. A dependency that crosses a gate is reported as a conflict with a one-click fix. Variants live in one board with one history.
Its two Jira roads are the two above: File ▸ Export ▸ Jira CSV, which Jira's external-system importer reads, and a JQL query that becomes a board. Both are built against Jira's documented formats and have not yet been run against a studio's live Jira. If yours rejects the file or the query, write to us and we will fix it first.
It is a Windows desktop app, currently in beta. What it is and what it does not do · Compared with a spreadsheet, Jira, HacknPlan and Codecks · Request the beta.