The ticket

The cheer feature, the one this whole act follows from idea to race morning, begins its life as a paragraph.

Spectators keep asking for one thing, at expo booths and in support emails and once on a napkin handed bodily to a member of staff: a way to send a message that reaches a runner mid-race. Dana, the product manager on Race Experience, writes it down. The written down thing is a ticketConcept · lights on your mapticketOne tracked piece of work (a feature, a bug, a task) with a description, an owner, a status, and a discussion thread. Engineers also say issue; the words are synonyms. It is the bridge between somebody wants something and somebody is building it.. A ticket is where wanting becomes work. Nothing at Traversal gets built without one, which sounds bureaucratic until the third time somebody asks who decided this and the answer is on file.

The list of everything

The ticket does not jump the queue. No ticket does. It lands in the backlogConcept · lights on your mapbacklogThe ordered list of all the work a team intends, or vaguely hopes, to do: tickets waiting their turn. Endless by nature. A healthy one is ruthlessly prioritised, and “it’s in the backlog” can mean next week or never., the long ordered list of everything Race Experience means to do someday. Cheer messages enter at position forty-something. By Thursday, on the strength of Dana’s argument and one well-timed customer email, it has climbed past four bug fixes, an infrastructure ticket, and a settings-screen redesign that has been near the top for a year and a half. Now it is the top.

The list lives in JiraConcept · lights on your mapJiraThe dominant, and dominantly grumbled-about, ticket-tracking product. Tickets, backlogs, boards, sprints: the planning layer’s filing cabinet. “It’s in Jira” means it is written down and tracked., the second and last real name this story keeps. Engineers complain about Jira the way runners complain about hills, which is to say constantly, while climbing.

What, not how

Inside the ticket, Dana has written what the feature must accomplish, seen from the outside: a spectator following a runner can send a short message, and the runner sees it during the race. That is a requirementConcept · lights on your maprequirementWhat the work must accomplish, stated from the outside. Requirements say what; engineers decide how. Vague ones are the leading cause of building the wrong thing., and the discipline in it is what it leaves out. Nothing about queues. Nothing about databases. The what belongs to Dana; the how belongs to whoever picks the ticket up.

On Friday, in a planning meeting with too many pastries, Finn picks it up.