Custom Issue Types The nine types you start with, and how to shape them around your own work.

Issue types are not fixed. The nine you start with are a sensible default, not a rule.

What ships

Task, Bug, Feature, User story, Improvement, Tech debt, Spike, Sub-task and Epic.

Each carries a label, an icon and a colour, and can be reordered so the ones your team uses most sit at the top of the picker.

Changing them

Types can be added, renamed, recoloured, reordered and deactivated. Deactivating rather than deleting is the safer move: existing issues keep their type and it simply stops being offered for new ones.

Worth doing sparingly

The instinct is to add types until they describe every kind of work precisely. Resist it. Types are for deciding how something is handled, and a list of twenty forces a decision nobody can make consistently.

Two questions before adding one:

Does it change what happens? If a Chore is handled exactly like a Task, it is a label, not a type.

Will people pick it correctly? A type only half the team recognises makes reporting worse, not better, because the same work lands in two buckets.

Most teams are better served by adding a label than a type.