From request to task · chapter 5 of 17
Goals, scope and completion criteria
A vague request becomes executable when we describe the desired effect, what belongs to the task and which checks demonstrate completion.
5.1 · plain explanation
How do we turn “can you fix this?” into an outcome that both the person and the agent can evaluate?
A vague request becomes executable when we describe the desired effect, what belongs to the task and which checks demonstrate completion.
Important: A completion criterion must be able to fail. If it can always be checked off regardless of the outcome, it is not a real control.
5.2 · building blocks
Three concepts to keep separate
Goal
What should become true for the user or the system?
Scope
Which pages, files, languages and environments are included, and what is explicitly excluded?
Completion criterion
An observable check, not merely an activity such as “the code was written”.
5.3 · method
A practical workflow
- 1Describe the desired effect.
- 2Name goals and non-goals.
- 3Write measurable acceptance criteria.
- 4Add stop conditions for unexpected risk or missing information.
5.4 · concrete example
A better desktop page
A better desktop page
How do we turn “can you fix this?” into an outcome that both the person and the agent can evaluate?
Vague: “Make the page look better.”
Clear: the main body must be at least 700 px at a 1440 px viewport, with no overlap or horizontal overflow, checked at four viewport sizes.
5.5 · try it yourself
Exercise
Rewrite three of your own requests using the fields goal, scope, non-goals, acceptance and stop condition.
5.6 · checklist
Before you continue
- Does the goal describe an effect?
- Are affected surfaces named?
- Is it clear what must not change?
- Can every completion criterion be checked?