Tickets and acceptance criteria

A ticket is the unit of work in Jarvis. It is what a person or an agent picks up, what a branch is named after, and what the approval screen checks the change against. A good ticket is small enough to review in one sitting, says what "done" means, and serves one outcome.

This page covers the fields on a ticket, how to write acceptance criteria, and the parts of a ticket an agent reads.

#The fields

Field	What it is for
Title	One line that says what changes. It becomes part of the branch name.
Project	Decides the repository, the notes and the goal the agent reads.
Outcome	Optional. The outcome this ticket helps deliver. Its progress counts this ticket.
Assignee	The person responsible. Agents are assigned separately, each time work starts.
Status	Where it sits on the board.
Priority	Low, normal, high or urgent.
Due and Sprint	When it is expected.
Story points and Estimate	Size, in points (half points allowed) and in minutes.
Description	The brief. The form says it plainly: this is what the agent reads.
Acceptance criteria	Two lists, plain and technical. See below.
Attachments	Screenshots, PDFs and other files the work depends on.

#Writing a ticket an agent can finish

An agent reads a ticket literally. What it needs has to be in the ticket, its conversation, or the project's goal and notes.

• One change per ticket. "Fix the cart total and redesign the header" is two tickets. A change that mixes two things is hard to approve and harder to undo.
• Say what, then why. The title says what changes. The description says why, who notices, and what must not change.
• Name the place, if you know it. "The total on the cart page" saves the agent a search and saves you a surprising change.
• Attach the evidence. A screenshot of the bug or a PDF of the design is worth more than a paragraph describing it.
• Link the outcome. It gives the agent the reason behind the ticket and gives the delivery lead an honest progress number.

If you cannot write the acceptance criteria, the ticket is not ready to be worked on, by a person or an agent.

#Acceptance criteria

Every ticket has two lists of acceptance criteria, written for two different readers.

List	Reader	Example
Plain	The client, or whoever signs off	The cart total includes the delivery charge once a postcode is entered.
Technical	The reviewer at the approval gate	The total is worked out in one place, not on each page. Existing cart tests still pass. A test covers a cart with no postcode.

Keeping them apart stops each list from becoming useless to the other reader.

#Drafting them

Press Draft With AI in the acceptance criteria panel. It drafts both lists from the title and the description, and the panel fills in when it is done. Redrafting replaces both lists, so make your edits after the last draft.

The draft is a starting point. Delete what is wrong and add what is missing: the reviewer will be held to these criteria, so they should be ones you agree with.

#Where they go

Both lists are given to the agent every time it works on the ticket, and shown again on the approval screen next to the change, so the reviewer checks against something written down.

#The conversation

Comments on a ticket form a thread. People reply to each other, attach files to a comment, and correct the ticket as they learn more. Comments from Jira appear alongside comments written here.

Agents read the recent conversation too. A ticket is corrected in its comments far more often than in its description, so this is how the agent hears about it.

You can start agent work from the conversation. Tick the box to run an agent when you post a comment, or press Run an agent under an existing one, and the assign dialog opens with that comment as the instruction. You still pick the agent and the options, the same as always.

#Attachments

Files are listed on the ticket with a note saying which ones an agent can read. Agents can read PDFs and images; other formats are kept for people. Your administrator sets how large an upload can be, and some file types are not accepted.

#Where tickets come from

Tickets can be written here or brought in from the tools your team already uses: Jira (with comments, attachments, story points and sprints), Trello, or GitHub issues. A ticket from another tool shows its original key in its own column on the task list, linked back to where it came from.

#The board and the workflow

Tickets can be viewed as a list or as a board. The statuses are set up under Task statuses, and the Workflow screen says which status may follow which. The board follows those rules, and a ticket can always be closed from wherever it is.

While an agent is working, the ticket moves through statuses of its own, such as Agent running and Awaiting approval. Those are set by the agent's progress, not by hand.

#Splitting a ticket

If a ticket may have an app side and an API side, Split it checks whether it really does and creates only the sides it has, each in the client's project for that repository.

If the app and API should change together in a single piece of agent work, link the two projects instead. See What an agent reads.

#Worklogs, branches and pull requests

• Worklogs: one entry per day per ticket, with minutes. The text is drafted from what actually happened that day.
• Branch: each ticket gets a branch named after its key and title, so every attempt on the ticket lands in the same place.
• Pull request: once approved work becomes a pull request, the ticket shows it with its live state. You can also link one opened by hand. People who can approve may be offered a merge button.

Next: Runs and the approval gate.