Pixie Works
AGILE · TICKET-DRIVEN DEVELOPMENT
Make tickets the team's shared language.
How a clear ticket connects planning, implementation, and review, whether a person or a coding agent writes the code.
Illustration generated for this article. It does not depict Pixie Works staff, clients, or an actual project.
The ticket exists. Implementation begins. Then someone asks: “What does done actually mean?”
That question often signals a gap between a task name and a shared understanding of the work. My approach to Ticket-driven development starts by making that understanding visible before anyone begins implementation. A ticket is a small agreement about an outcome, not merely an item to move across a board.
Give each ticket a purpose, scope, and finish line
A useful ticket answers three questions: Why does this work matter? What is included? How will we know it is complete? The answer need not be a long specification, but it should be concrete enough for someone else to implement and review.
For example, “improve the contact form” leaves room for different interpretations. “Show a confirmation after a valid submission, record whether delivery succeeded, and verify both Japanese and English routes” gives the team something it can check. The ticket can link to supporting requirements and decisions rather than copying them all into one field.
Connect planning to the evidence of completion
Jira can hold the backlog, priorities, and sprint work. Confluence can preserve requirements, design choices, and the reasons behind decisions. In Scrum, the team uses these records during planning, progress checks, reviews, and retrospectives. The ticket connects them to the change that was actually made and the evidence that it works.
When a review exposes a missing case, we update the ticket or create the next one. This keeps the team's knowledge tied to real work rather than buried in a conversation that only a few people remember.
Give coding agents the same clarity
A coding agent can help implement a ticket, but an unclear request does not become clear just because it is sent to AI. We translate the ticket's purpose, boundaries, and completion criteria into instructions. We ask for the implementation and relevant tests, then a person inspects the change, its test results, and any remaining uncertainty before accepting it.
This is the starting point for how we teach AI-DLC: the team stays responsible for the outcome, while the agent works within a reviewable task. The next ticket can incorporate what the team learned.
Start with one real ticket
Choose a task your team is about to start. Write its purpose in one sentence, define the boundary, and agree on two or three observable completion criteria. Link the background decision. At review, compare the result with those criteria and record what changed. Repeat before changing every process at once.
The aim is a shared language for people and AI tools, from the first planning conversation to the final human check.