Engineering ·
Define what done means before the build starts
A shared definition of completion connects a feature to the task it must support. Include user behavior, failure handling and the way acceptance will be checked.
By Norwind
Start with an observable outcome
A feature is difficult to accept when its description says only that a screen should exist. Describe what the user must be able to complete and which business rule the result must satisfy. For a form, that includes what happens after submission. For a report, it includes the meaning of the records shown. Acceptance becomes clearer when people can point to behavior rather than interpret an adjective.
Include the cases that make the work difficult
Missing information, duplicate submissions and restricted access should not be surprises at the end. Choose representative exceptions with the people who know the workflow. Decide which belong in the first release and which will be handled another way. A clear scope can leave work out, provided the team understands the consequence and has a practical way to operate without it.
Agree who checks the result
Name the person who can confirm the business behavior and the evidence they will use. Keep technical checks and business acceptance connected without treating them as identical. Automated tests can protect a rule while a user confirms that the overall task is workable. Review acceptance criteria when the scope changes. A shared finish line helps the team discuss tradeoffs before a disagreement becomes a launch-day problem.
A practical check
- Describe the task a user must finish.
- Agree how failures and restricted access should behave.
- Name the business reviewer and the evidence of acceptance.