Work management
Boards and workflow
States defined once for the whole organisation, and boards as views over them.
States belong to the organisation
Workflow states are defined once and shared. Each has a name, a position, a colour and a category — the category is what the product reasons about, so a team can call a state whatever it likes without breaking cycle-time or done-ness.
One vocabulary across every project
Per-project workflows sound flexible and produce an organisation where nobody can read anybody else's board, and where *done* means six different things. With one set of states, an item pulled from another project into this sprint arrives meaning what it appears to mean.
One state is marked as the initial state: it is where new work lands. An organisation with no initial state cannot create work items, and says so rather than failing quietly.
Boards
| Board | Behaviour |
|---|---|
| Scrum | Shows the active sprint. Work is committed in advance. |
| Kanban | Shows flow. Columns can carry a work-in-progress limit. |
A board is a set of columns, and each column maps to one or more states. That indirection is what lets a board group three states into one column — *In review*, *In QA* and *Blocked* under a single heading — without changing what an item's state actually is.
Scope
- Organisation
- Everything. The default, and the one that matches the cadence.
- Project
- The same board with one filter applied.
- Team
- The work a team is carrying, across whatever projects it spans.
Editing a board
Boards, their columns and their work-in-progress limits are maintained under Settings → Boards. Each column names the states it shows, and a state left off the board is called out — work in that state would simply not appear.
Rebuilding a board's columns moves no work
An item carries a state; a column is only how one board groups states for display. So columns can be replaced wholesale without touching a single item — which is exactly why the same state may not appear in two columns of one board, since the item would show twice and dragging it would be ambiguous.
Naming your own states
States are maintained under Settings → Work management setup, alongside item types. The names are yours — *In review*, *With the client*, *Awaiting QA* — and what the product reasons about is the category: not started, being worked on, finished. That is why a custom name costs nothing. Cycle time, done-ness, backlog filtering and sprint completion all read the category.
There is deliberately no blocked state
Blocked is an overlay rather than a place work sits — see Blocking and links. A blocked state would throw away what the item was actually doing, which is the workaround this product exists to avoid.
- Exactly one state is where new work lands, and it cannot be cleared or deleted — without it nothing can be created, and the failure would appear when somebody tries to write down a piece of work.
- A state holding work cannot be deleted. An item has to be somewhere.
- Changing a state's category is allowed but recorded with both values, because it silently restates history: items in that state become finished, or stop being finished, and every completion figure computed from them moves.
Not built yet
Columns are ordered with buttons rather than dragged, and there is no card layout to configure — a card shows what it shows. Swimlanes and saved views both exist: swimlanes are on this page, and saved views have their own.