Custom Statuses and Properties

Custom statuses

Statuses are the board's columns, configured under Settings → Custom Statuses. You can add, rename and reorder them.

The rule that matters: a status should correspond to a real handoff — a point where the work changes hands, or changes what it is waiting on. 'In Review' is a status because the work moved to a different person. 'Nearly done' is not, because nothing changed hands; it is a feeling about progress, and feelings do not belong on a board where cycle time is computed from column transitions.

Apply that test and most boards land on four to six columns. The ones that reach nine or ten almost always have two or three that nobody can define, and those columns are where work goes to be forgotten.

One consequence worth naming: statuses feed cycle time, burndown, WIP limits and automation triggers. Renaming a status is cosmetic; adding one changes what your flow metrics measure. Do it deliberately, and expect the first fortnight of numbers afterwards to be a transition rather than a trend.

Custom properties

Custom properties are workspace-defined fields on tasks, configured under Settings → Custom Properties. They carry real types — dropdowns with defined options, numbers, dates, text — and the type is not cosmetic: it decides how you can filter, sort and report on the field.

The decision to make is between a dropdown and free text, and it is almost always dropdown. A free-text field called 'Client' produces 'Acme', 'acme', 'Acme Corp' and 'ACME' within a month, and none of them group. A dropdown is more work to set up and is the only version you can actually query.

The test for whether a property should exist at all: would you ever want to answer a question by this field — filter by it, group by it, put it in a report? If yes, it is a property. If it is context a human reads once, it belongs in the description.

The Jira-style taxonomy

There is a whole configuration surface that has no sidebar link at all, reached by navigating to Settings → Issue Configuration directly. It is worth knowing about because it fills gaps people otherwise work around.

Issue types and resolutions are workspace-level: Bug, Story, Task, Spike; Fixed, Won't Fix, Duplicate, Cannot Reproduce. If your team already thinks in those terms — most teams migrating from Jira do — this is where you keep them rather than approximating them with labels.

Components and versions are per project. Components are the parts of the system a task touches; versions are the releases it belongs to. Together they are what makes 'what is left for 2.4?' a query rather than a spreadsheet.

The project key prefix is also here, on the Project Keys tab. It is what turns task identifiers into ENG-114, which matters more than it sounds: a short stable key is what people paste into chat and commit messages.

Knowing when you have overdone it

Configuration has a cost that shows up later and on other people. Three signals.

A column nobody can define. Ask two teammates what 'Staged' means and get two answers — that column is a place work goes to be forgotten.

A required property that people fill in with the first option to get past the form. That field is now noise in every report that uses it, and it is worse than not having it, because it looks like data.

A taxonomy nobody uses. Six issue types where the team only ever picks two means the other four are a decision people have to make and then not use.

The fix in all three cases is subtraction. Deleting a column, a property or a type is a small piece of work and it makes the board more honest immediately.