Skip to content

Task properties

A task needs a title. Everything else on this page is optional, and the teams that stay happy are the ones that add a property when it answers a question somebody actually asks.

Property Answers
Status Where is it in the workflow?
Assignee Who is doing it?
Priority What do I pick up first?
Type What kind of work is this?
Labels How do I find this again later?
Estimate How big is it?
Due date When is it needed?
Sprint Which time box?
Module Which part of the product?

Every one of them can be set without opening the task. Hover a card or a row and press the letter — S status, A assignee, P priority, L labels, T type, E estimate, C sprint, M module.

Five values: None, Urgent, High, Medium, Low.

The list is short on purpose. A priority scale with nine levels turns into a scale with two, because nobody can tell 6 from 7. Sort a view by priority and the top of the list is the answer to “what now?”.

What kind of work a task is — Bug, Feature, Chore, whatever your team says. Types are defined per project, so a support project and a product project do not have to share a vocabulary.

Types are how you split a board without splitting a project: filter to Bug and the same board becomes a bug tracker.

Free-form tags. needs-spec, design, customer-reported.

Labels are the one property your team owns rather than your admin:

  • Type a name that does not exist yet and the picker offers to create it, colored on the spot.
  • Got the color wrong? Hover the label, hit the pencil, rename and recolor it right there. No settings page, no leaving the task.
  • Guests can apply your labels but never invent or rewrite them.
  • Only an admin can delete a label, because deleting one removes it from every task at once.

Use labels for things that cut across statuses and projects. If the tag is really a stage of work, it wants to be a status. If it is really a workstream, it wants to be a module.

Every project picks one estimate scale, and every task in it uses that scale.

Scale Looks like Good for
Points 1, 2, 3, 5, 8 Teams that already do story points.
T-shirt XS, S, M, L, XL Teams that want size without arithmetic.
Time 2w, 3d, 4h, 30m Teams that bill or plan in hours.

On the time scale you type the way you talk. 2w is two weeks, 4h 30m is four and a half hours. There is no unit dropdown.

Estimates feed the sprint burn-up and sit next to tracked time on the task, so “we thought four hours, it took eleven” is a fact you can see instead of a feeling you have. See Track time.

A task can carry a start date and a due date. Both are optional; a task with neither simply does not appear as a bar on the timeline.

Dates are what the timeline draws, what dependency arrows push around, and what turns into “6w left” or a red “12d late” on a project card.

When the built-ins run out, define your own. Seven kinds:

Kind Holds
Text A short free-form string — Customer, Environment
Number A quantity, with an optional unit shown before or after
Date A single date
Checkbox Yes or no
Select One or more values from a list you define
Member One or more people from the workspace
URL A link, rendered clickable

Custom fields behave like built-ins everywhere it matters: you can filter by them, show them as list columns, set them in bulk, and read or write them from the API and from an agent over MCP.

An empty property does not clutter the task. If nothing is set, most properties simply are not shown — the exception is Status, which every task always has and always displays.

This is why an unfilled task looks calm instead of looking like an unfinished form.