Work management
Coming from Jira
What maps directly, what is called something else, and the four habits worth unlearning.
Jira is the baseline this was built against, so most of it transfers without thinking. The differences are few and deliberate, and three of them exist because Jira's answer is the thing teams work around rather than with.
What is the same, under another name
| Jira | Here | Note |
|---|---|---|
| Issue | Work item | Same thing. |
| Issue type | Work item type | Configurable, with a numeric level instead of a fixed epic/story/subtask ladder. |
| Status | Workflow state | Yours to name. The category behind it is what the product reasons about. |
| Epic | A type at a higher level, or an initiative | An epic that stays inside one project is a type. One that crosses projects is an initiative — Jira has no equivalent. |
| Version / fix version | Release | Same idea, with unfinished work refused rather than silently carried. |
| Sprint | Sprint | Organisation- or team-scoped rather than board-scoped. |
| Component | Label or custom field | Depends whether you want a flat word or a typed answer. |
| Filter | Saved view | A URL rather than a query language. |
| Board | Board | A grouping of states for display. Changes nothing about the work. |
The four habits worth unlearning
- Moving a blocked item back to To Do
- The standard Jira workaround, and it destroys the fact that the item was in progress — leaving somebody to remember to move it back. Here blocked is an overlay, derived on every read from the links. Mark what blocks what and the badge appears; finish the blocker and it clears itself, with no write and nothing to remember. See Blocking.
- One board per project, one sprint per board
- An agency running eight clients through one team ends up with eight boards and adds up by hand. Here the cadence is organisation- or team-level, and a project view is a filter over the one backlog rather than a separate list to reconcile. See Cadences.
- A custom field for everything
- Jira makes fields cheap to add and expensive to live with. Here a field's key and type are fixed once it holds values, precisely so the ones you do add stay trustworthy. Reach for a label when you want a word, and a field when you want an answer you will filter on.
- Writing JQL
- There is no query language. Filters are controls, and the resulting URL is the query — shareable, back-button-able, and saveable. It covers less than JQL does, on purpose: the first ten percent of JQL is what people actually use, and the rest is a moat rather than a feature.
What genuinely is not here
- No workflow transitions. Any state can move to any state. Transition rules, conditions and validators are Jira's largest configuration surface and its largest source of *why can I not move this*.
- No permission schemes per project. Access is organisation-level by role, with a guest role for somebody watching one project.
- No screens or field configuration schemes. A custom field applies to the item types you choose and that is the whole model.
- No JQL, no dashboards, no gadgets. Insights reports a fixed set of things well rather than a builder for anything.
- No plugin marketplace.
There is no importer yet
Work items, comments and history have to be moved through the API or entered by hand. This is the honest blocker on migrating a large Jira instance and it is known — see What is not built yet.
What you gain by moving
- Sprint capacity from real availability — scheduled hours minus public holidays minus approved leave, per person, because the leave is in the same database as the sprint. Jira computes capacity from a number somebody typed.
- One backlog across every client, in a single order, rather than a merge of per-project lists.
- Blocked that clears itself, as above.
- A release that cannot claim work it did not ship.
- Cycle time reported as percentiles, so one six-month outlier does not set your forecast.