A ticket system makes a technology team’s work visible: what people are doing now, what is scheduled, and what remains open. Each ticket is an identifiable unit of work assigned to a person. Tools vary; the important part is a shared way to record and follow the work. section 9.1.1
Agree on a few working rules:
- Give each ticket a unique identifier and an owner. Move it through a lifecycle from open to closed; closing can mean either completed or deliberately set aside as irrelevant. section 9.1.1
- Tell the team what a ticket represents. Group related work into epics, stories, or projects, and use subtickets where useful. section 9.1.1
- Choose a manageable ticket size. For example, if the limit is four hours, split work expected to take longer into a series of tickets. section 9.1.1
Plan for maintenance before it becomes urgent
Yearly maintenance may take team members away from other work for upgrades. Include it in the plan and account for that capacity when setting expectations with the CEO and board, rather than reacting only when the work is due. section 9.1.1
A useful check is whether all team work is tracked through the ticket system and projects follow a defined planning cadence. Jira is one example, not a prerequisite; alternatives use the same underlying ticket principle. section 9.10 section 9.1.1
