A card for a piece of work
Think of a ticket as a card on a team’s shared planning board, like a note pinned to a corkboard. It gives a piece of work a name, status, context, and place for discussion. Bugs, research, design changes, and engineering tasks can each have a ticket.
A user story is one way to describe a ticket in terms of its value: “As a returning customer, I want to reuse my delivery address so that checkout takes less time.” It keeps the focus on who benefits and why. Technical tasks may need a different format.
Planning tools often number tickets, so teammates might refer to “ticket 123”. Depending on the team’s process, anyone may create one, including on another team’s board to report a bug.
Useful tickets require consideration
Detail does not guarantee clarity. A short ticket may be enough when the team shares the context; otherwise, more explanation helps. Include what people need to make sound decisions.
Useful tickets often include the problem, desired outcome, acceptance criteria, designs or evidence, and known constraints. A story should be small enough to discuss and complete; a larger outcome may need several tickets.