Pixie Works
AGILE · TICKET-DRIVEN DEVELOPMENT
What belongs in a ticket? A practical example of Why, What, and How.
Turn “improve the contact form” into a clear purpose, defined scope, and observable completion criteria that guide implementation and review.
Illustration generated for this article. It does not depict Pixie Works staff, clients, or an actual project.
“Improve the contact form.” Would everyone on your team picture the same work from that title?
One person might change the layout. Another might remove fields. You may have meant to improve the message shown after submission, only to discover the difference once implementation has begun.
The first article described a ticket as a small agreement about an outcome. This time, we will use a fictional contact form to make that agreement concrete. This is an illustrative example, not a report about a client project or an actual incident.
Why: Start with the user's problem
“Make it easier to use” leaves the direction open. For this example, we can state the purpose as:
Help people submitting an inquiry understand whether their submission has been accepted.
Choose one purpose first. A clear purpose helps the team decide whether a proposed change belongs in the work.
What: Define the scope of this change
Decide what the team will change to serve that purpose.
On the Japanese and English contact forms, show an acknowledgment when submission processing succeeds. For input errors, identify the fields that need correction. Adding fields, redesigning the whole site, and changing the email delivery infrastructure are outside this ticket's scope.
Stating exclusions helps distinguish this piece of work from improvements that belong in another ticket.
How: Make completion observable
Here, How covers how the team will establish that the work is complete, as well as how it is implemented. For this example, agree on three conditions:
- When required fields are valid and submission processing succeeds, an acknowledgment appears in the current display language.
- When a required field is missing, an error identifies that field and no success acknowledgment appears.
- When submission processing fails, the form does not claim success and explains how to retry or use another contact method.
A success acknowledgment and an email arriving in the recipient's inbox require separate checks. If inbox delivery is part of this ticket's completion criteria, include who will confirm receipt and how.
Connect Jira and Confluence to evidence of completion
Use Jira to manage the assignee, priority, and progress of the sprint work (Delivery). Use Confluence to preserve requirements, the reasoning behind the wording, and the options considered (Discovery).
Link to the relevant pages instead of repeatedly copying the same explanation. After implementation, connect the PR, verification results, and any necessary screenshots to the ticket. A team member reviewing the work should be able to compare each condition with its result.
Give coding agents the same ticket
When a coding agent implements the change, carry forward the purpose, scope, and completion criteria. Add the relevant files, existing implementation, and constraints it must follow.
Clarify unknowns before implementation, then have team members review the generated changes and verification results. If a new requirement emerges, decide whether to revise the current scope or create the next ticket.
Start with one ticket in the next sprint. Is its purpose clear? Is the scope defined? Can someone else verify that it is complete? Those three questions are a practical starting point for a team discussion.
Our Agile coaching and training use real work to help teams put Ticket-driven development and AI-DLC into practice.