How Mermix schedules your Jira issues
When you sync a Jira issue into Mermix, the planner looks at four signals on the issue and decides where it should land — on the calendar (with concrete start + end dates) or in the backlog (waiting for the planner to pick a date). This document explains the rules, why they're shaped this way, and what you can do when you'd place something differently.
This is the customer-facing companion to configuring Jira for Mermix: that side covers the upstream Jira configuration; this one covers what Mermix does with the result.
The four signals
Mermix reads four pieces of information per Jira issue:
| Signal | Where it comes from in Jira |
|---|---|
| Assignee | The issue's assignee |
| Start date | A start-date field: the Start date built into Jira, or the date field linked in Portfolios → Workspace → Jira fields |
| Due date | The issue's Due date |
| Effort | The issue's Original estimate (time tracking) |
Whether a field is "set" depends on the value being non-null in Jira. An 8-hour effort estimate counts as set; a missing estimate doesn't.
The 9 outcomes
The four signals combine into nine outcomes. Mermix picks one per issue based on which signals are present:
Unassigned issues — always go to backlog
If assignee is empty, Mermix sends the issue to the backlog regardless of
dates or effort. There's no point reserving calendar time for an issue with
no one to do it. Once you assign it in Jira, the next sync moves it to the
calendar (if other signals support it) or leaves it in the backlog.
This is the "unassigned" row in the assignment-gated matrix below.
When a task already on your calendar loses its assignee in Jira (or is given to someone who is not in your team), the next pull lists it and lets you choose. Tick it and it moves to the backlog, keeping the dates Jira holds. Untick it and it stays with the person on your calendar; Push to Jira then offers to assign it back. If the task has changes you have not pushed yet, it is not ticked for you.
Assigned issues — eight cases
When the issue has an assignee, Mermix looks at start / end / effort and picks one of eight cases:
| Case | Has start? | Has due? | Has effort? | Outcome | Where it lands |
|---|---|---|---|---|---|
| B1 | ❌ | ❌ | ❌ | No usable signals | Backlog |
| B2 | ❌ | ❌ | ✅ | Sequenced from estimate | Calendar (back-to-back with the resource's other tasks) |
| B3 | ❌ | ✅ | ❌ | 1-day at due date | Calendar (single day pinned to the due date) |
| B4 | ❌ | ✅ | ✅ | Back from due date | Calendar ([duedate − ⌈effort/8⌉ working days, duedate]) |
| B5 | ✅ | ❌ | ❌ | 1-day at start date | Calendar (single day pinned to the start date) |
| B6 | ✅ | ❌ | ✅ | Forward from start | Calendar ([start, start + ⌈effort/8⌉ working days]) |
| B7 | ✅ | ✅ | ❌ | Honour Jira dates | Calendar (exact dates) |
| B8 | ✅ | ✅ | ✅ | Honour Jira dates | Calendar (exact dates; effort respected as duration on the bar) |
Working-day arithmetic. When Mermix derives a start or end date from effort (B2, B4, B6), it counts only working days — Saturdays and Sundays are skipped, and so are the public holidays of the resource's country (read from each resource's ISO country code). A 16-hour estimate (2 working days) starting Friday lands the next Monday; the same estimate starting on a UK holiday lands the day after.
Weekend / holiday duedate shifts. If a Jira issue has a duedate or start date on a weekend or holiday, Mermix only shifts the date for single-day cases (B3, B5) — to the previous working day for due-date anchors and the next working day for start-date anchors. For multi-day cases (B4, B6), Mermix keeps the customer's deadline as the end and computes the other endpoint via working-day arithmetic, which naturally lands on a weekday.
Past dates are honoured. If the duedate is in the past, Mermix still schedules at that date — the calendar's overdue styling makes the past visible. Same with effort that would push the start date into the past. Mermix presents reality rather than silently shifting things to look clean: the overallocation indicator and overdue tints surface the impossibility honestly.
Where you see how each issue was placed
- The Pull from Jira window — each new issue says what will happen to it (for example Back from due date) before you click Import.
- The summary after an import — two groups. On your calendar, split into From Jira start + due dates, Inferred from due dates and Sequenced from estimates; and In your backlog, split by why: waiting for an assignee, assigned to someone not on your team, no dates or estimate, or waiting on work that has no dates yet.
- The Excel export from that summary — every issue with a sentence saying how it was scheduled.
Changing where an issue lands
- Before importing: untick an issue in the Pull from Jira window and it is not imported this time.
- After importing: drag a bar on the calendar to change its dates or person, drag it to the backlog to unschedule it, or drag a backlog card onto the calendar. These are planning changes you can push back to Jira.
- In Jira: set a start date, due date or estimate and pull again; the rules above place it from the new data.
Scheduling several backlog tasks at once
In the backlog, click Select, tick the cards you want, and click Schedule. Choose the person who will do them.
- Tasks are placed one after another in priority order. Each task goes where that person first has free time for it, starting today. Their work in every portfolio, their working pattern, public holidays and approved leave all count, so nothing lands on a day they cannot work.
- A task with no estimate takes two working days.
- Schedule stays greyed out until you choose a person. If every card you ticked has the same assignee in Jira, and that person is on your plan, they are chosen for you.
- The window warns you about any task that will go to a different person than its assignee in Jira.
- The new dates (and any change of person) are marked to push back to Jira, like any other planning change.
Edge cases
No effort and no due date — issue lands in backlog (case B1). To get
it onto the calendar without manual scheduling, set a timeoriginalestimate
in Jira and pull again. Mermix will sequential-schedule it after your other
tasks (case B2).
Effort larger than the duedate window — Mermix computes
start = duedate − ⌈effort/8⌉ working days, which can land in the past.
The bar will show as starting in the past with an overallocation
indicator. Either trim the estimate, push the duedate, or reassign — the
honest visualisation is the diagnostic.
Resource has a public holiday during the computed window — the working-day arithmetic skips holidays for the resource's country, so the bar effectively gets longer to accommodate. A 5-day estimate starting before Christmas in Greece spans into the new year.
Issue gets re-pulled after schedule has been adjusted — the helper re-runs on every fetch and produces the same dates (it's deterministic given the same Jira inputs). The diff detector then sees that the incoming dates match what's already stored, so re-pulls don't generate spurious "Updated" badges.
No per-workspace rules
There is no setting to change the rules themselves. Mermix uses one predictable set of rules for every workspace; to place an issue differently, use the options in Changing where an issue lands above.
Related: How to configure Jira for Mermix — set the signals above so Mermix schedules well · Pushing your plan back to Jira — send your adjustments back.