Outcomes and quality checks

An outcome is a lasting capability the system must have for the project to reach its goal. It sits between the goal and the tickets: the goal says where the phase is going, the outcomes say what the system must be able to do when it gets there, and the tickets are the work that makes each outcome true.

Outcomes live on the project's Outcomes tab. This page covers how to write them, the six quality checks every outcome has to pass, and the AI review that gives you a second opinion. It belongs to the Plan job in How we deliver.

#What an outcome is, and is not

An outcome describes something a user or the system can do. It is not a piece of work, and it is not a list of features.

This is a task	This is a feature list	This is an outcome
Add a saved cards table.	Saved cards, card editing, default card, expiry warnings.	A returning customer can pay with a card they saved earlier, without typing it again.
Write the export.	CSV export, spreadsheet export, date filters.	An account manager can export one client's monthly hours in a format the client accepts.
Upgrade the framework.	New router, new mailer, new background jobs.	The application runs on a supported framework release with no change in behaviour for users.

The test is simple: an outcome stays true after the work is finished, and you could still check it a year later.

#Fields

Each outcome has three fields.

• Title: the capability, in one sentence. This is what people see in the ticket form.
• Description: how you would tell it is true, the edges that matter, anything that is out of scope.
• Status: where it is in its life.

#Statuses

Status	Meaning
Proposed	Written down, not yet checked. It may still change.
Ready	All six quality checks are ticked. It is clear enough to plan tickets against.
In progress	Tickets linked to it are being worked.
Delivered	The capability exists and has been checked.
Retired	No longer needed for the goal. Kept so the history of the project still makes sense.

Ready, In progress and Delivered all say the outcome passed its checks, so Jarvis only lets you choose them once all six checks are ticked.

#The six quality checks

Each outcome has six checkboxes. Tick one when the outcome honestly passes it.

Check	Question to ask
An outcome, not a task	Does it describe something a user or the system can do, rather than work to be done?
Distinct	Does it stand apart from every other outcome, without overlap?
Testable	Could someone check that it is true?
Lasting	Will it still matter after this phase ends?
Clear	Can it be understood without its author explaining it?
Serves the goal	Does delivering it move the project toward its goal?

#When a check fails

• Not an outcome. Rewrite it as what someone can do once the work is finished. "Build the export" becomes "an account manager can export a client's monthly hours".
• Not distinct. Two outcomes overlap. Merge them, or move the shared part into one and narrow the other.
• Not testable. Add how you would tell. "Fast checkout" is not testable; "checkout completes in under three seconds on the staging site" is.
• Not lasting. It is probably a task or a milestone. Turn it into a ticket under a real outcome.
• Not clear. Hand it to someone who was not in the meeting. Whatever they ask, put the answer in the description.
• Does not serve the goal. Either the outcome belongs to a different phase, or the goal is missing something. Fix whichever is wrong.

Three to seven outcomes is normal for a phase. Fewer usually means they are too broad; many more usually means some are tasks.

#Linking tickets

The task form has an optional Outcome field. Each ticket links to one outcome at most. A ticket that does not serve any outcome is worth a second look: it might be maintenance, which is fine, or it might be work nobody asked for.

Each outcome shows its progress as closed tickets out of linked tickets. That tells you how much planned work is finished, not that the outcome is true: marking it Delivered is still a person checking it against its description.

When an agent works on a ticket, it is told the project goal and the ticket's outcome. That tells it why the ticket exists, which helps with the small judgement calls a ticket never spells out.

#Review with AI

The Review with AI button on the Outcomes tab asks an AI model for a second opinion. The review takes a little while; the tab shows it working and fills in the results when it is done.

The model reads the project goal, the notes and every outcome, and returns:

• Per outcome, per check: a pass or a concern, with a one-line reason.
• Gaps: parts of the goal that no outcome covers.
• Overlaps: outcomes that cover the same ground.

The review is advice only. It never ticks a box or changes a status, because a person is accountable for saying an outcome is Ready. Treat a concern, or a pass, as a prompt to reread the outcome: the model can be wrong either way.

The button is available once your administrator has connected an AI model to the workspace.

#Who can change outcomes

Adding, editing and checking outcomes, and starting a review, needs the Manage outcomes permission on your group. Ask your administrator if you need it.

#A worked example

Goal: An account manager can send a client their monthly timesheet without editing it by hand, from the end of this quarter.

1. Proposed: "Export timesheets." Fails An outcome, not a task and Testable.
2. Rewritten: "An account manager can download one client's hours for a month as a spreadsheet in the client's own layout." Passes all six once the description says which layout and which columns.
3. Marked Ready. Three tickets are linked: the report, the spreadsheet layout, the download button.
4. The tickets close and progress reads 3 of 3. The delivery lead downloads a real month, sends it to the client, and marks the outcome Delivered.

Next: Tickets and acceptance criteria.