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 how to override them.
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 | Source | Required scopes |
|---|---|---|
| Assignee | assignee.accountId |
read:jira-user |
| Start date | Configurable custom field, defaults to customfield_10015 |
read:issue-details:jira |
| Due date | Standard Jira duedate field |
(standard) |
| Effort | Standard Jira timeoriginalestimate field |
(standard) |
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.
Assigned issues — eight cases
When the issue has an assignee, Mermix looks at start / end / effort and
picks one of eight cases (B1-B8 in our internal docs):
| 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.
Signal labels
Each scheduled issue carries a signal value that explains how Mermix
chose its dates. You'll see these labels in three places:
- The Jira pull picker — small italic pill next to each issue's action sentence, before you click Sync.
- The post-sync summary chip — the banner at the top of the calendar right after a sync completes, grouped into 4 categories.
- The Excel export — every row carries the granular signal in its own column.
| Signal value | Picker label | Excel column | Outcome chip group |
|---|---|---|---|
jira_dated |
Scheduled from Jira dates | Scheduled from Jira dates | From Jira start + end dates |
back_from_duedate |
Back from due date | Back from due date | Inferred from due dates / start dates |
duedate_anchor |
1 day at due date | 1 day at due date | Inferred from due dates / start dates |
forward_from_start |
Forward from start | Forward from start | Inferred from due dates / start dates |
start_anchor |
1 day at start | 1 day at start | Inferred from due dates / start dates |
sequenced |
Sequenced from estimate | Sequenced from estimate | Sequenced from estimates |
backlog |
(none — backlog row) | Backlog | Sent to backlog |
Manual override — drag to the Backlog tab
The picker shows two tabs: Calendar (assigned + dated) and Backlog (unassigned + undated). Mermix's helper auto-classifies each issue into one of these tabs using the matrix above, but you can drag an issue between tabs before clicking Sync. The commit honours your choice:
- Calendar → Backlog: the issue lands in the backlog regardless of dates / effort. The Excel export records it under the Backlog sheet, with the original signal preserved for transparency.
- Backlog → Calendar: requires an assignee + at least one date or effort signal. If you drag an unassigned issue to Calendar, the commit silently routes it back to Backlog (it has no resource to schedule to).
Manual overrides are not persisted — the next sync re-classifies the issue based on its current Jira signals.
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 re-sync. 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 moves between tabs in the picker after fetch — the picker's
auto-classification is what the helper computed at fetch time. If you
drag an issue, the commit honours your choice. The post-sync chip will
classify based on where the issue actually landed (backlog for any
backlog-bound issue, regardless of original signal).
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.
When Mermix's choice doesn't match yours
The 9-outcome matrix is opinionated — it's how Mermix interprets a Jira project's data. Two override paths:
- Override per issue in the picker (drag to a different tab before clicking Sync).
- Override per project by changing the upstream Jira data — set a start date in Jira, refine the estimate, etc. The next sync picks up your changes.
There is no "scheduling rules" UI to override the matrix globally — Mermix prefers a single predictable algorithm over per-tenant customisation that can drift out of sync with real-world data.
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.