Aglet

Triage work with unclear acceptance criteria safely

Unclear acceptance criteria make every later status subjective. Triage should identify the intended outcome, separate acceptance from implementation preference, and expose the smallest unanswered question that prevents a trustworthy completion decision. A clear done condition describes an observable outcome, including the cases where the system should reject or recover.

Establish what is happening

  1. State the intended outcome

    Describe who needs what behavior, under which starting state, and what observable result counts as success. Separate customer or system outcome from a proposed screen, query, or code approach. Name the actor and starting state so success is testable outside the implementer’s assumptions.

  2. Add boundaries and rejection

    List meaningful roles, inputs, empty states, failures, permissions, retries, and out-of-scope behavior. Mark which cases are required, intentionally unsupported, or unknown instead of assuming the happy path represents completion. Include the edge state most likely to create a different pass decision.

  3. Assign criteria ownership

    Choose the person or role authorized to resolve ambiguity, record open questions, and set a review point. Keep work provisional until acceptance can be assessed against observable evidence. Give one role authority to resolve the remaining acceptance question.

What to carry forward

The output is an acceptance brief with observable success, meaningful boundaries, owner, and unresolved questions. Stop triage when a reviewer can tell what evidence would pass or fail; do not use implementation completion as a substitute for outcome agreement.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow