What to check before development
Use this checklist in refinement. A “no” is a prompt to discuss the ticket, not an automatic rejection.
1. Goal
- What problem are we solving, what result do we want, and for whom?
- Can the team explain the value of this change without describing the implementation?
2. Scope
- Which screen, service or flow is included? What is outside this task?
- Has one ticket quietly grown into several independent changes?
3. Expected behaviour
- What action is available, what should the user see, and what counts as success?
- Is the current behaviour different from the requested behaviour?
4. Roles and permissions
When access matters, identify who can perform the action and who cannot. Check whether a permission already exists. Do not invent a new role because the ticket omits one.
5. Edge cases and errors
Consider only cases that could change the implementation. For an invoice export, empty results and a failed request matter; dozens of hypothetical file names probably do not. If failure is possible, decide what the user sees, whether retry is possible and whether partial success can occur.
6. Dependencies
Is the necessary API, design, content, data or access available? Is another task required first? Link the source of truth and name an owner for each open dependency.
7. Acceptance criteria
Can the team tell whether the work is done? Write observable conditions from confirmed requirements. The acceptance criteria guide shows how to avoid turning assumptions into requirements.
Blocker or ordinary question?
A blocker is a decision whose answer may change the solution or make implementation unsafe. If nobody knows whether a payment is one-off or recurring, the payment flow cannot be designed responsibly.
An ordinary question can be closed during the work without undoing a meaningful step. If a button must use an established design system but its final label is “Download” or “Export,” work on the export logic can often begin. The owner and due point for the label should still be recorded.
The boundary depends on the task and team. Definition of Ready versus acceptance criteria explains the start decision. Once the important gaps are closed, estimate the task. You can also paste your ticket into the task readiness tool to surface missing decisions before refinement.