🗒️ An excerpt from my good, ol' Jira Team Runbook.
Acceptance Criteria tactices are ever evolving, but this is a good skeleton to start from.
- User story
- Functional requirements
- Link to design docs / supporting resources
- Technical breakdown and analysis to identify infrastructure dependencies
- Qualification of issue against SLA Matrix & inclusion of all derived NFRs
- Qualification of issue against Security Matrix/Guide & inclusion of all derived NFRs
- Qualification of issue against Observability Requirements Matrix/Guide & inclusion of all derived NFRs
- Qualification of issue against Monitoring & Alerting Matrix & inclusion of all derived NFRs
- Qualification of issue against Continuity Matrix/Guide & inclusion of all derived NFRs
- Qualification of issue against Documentation Requirements Matrix/Guide & inclusion of all derived NFRs
- Qualification of issue against Risk Matrix & inclusion of all derived NFRs
- Qualification of issue against Notification Matrix & inclusion of all derived NFRs
An example for the SLA NFR consideration:
Does the issue intersect with UX considerations? If yes, the performance unit tests must meet or exceed UX SLAs for the specific component class, and all dependents must be flagged for review of their performance integration tests by the performance engineer for potential changes to their performance objectives due to the introduction of this new code.
While the SLA considerations are numerous, other NFRs can be fairly straight forward. The Risk and Notification NFRs, for example, simply indicate the work necessary to ensure that the appropriate parties are notified of the deployment of a work item.
There are potentially dozens of NFRs that could apply to an issue. That said, the first one you must have noticed missing was The Nines, but regardless, this list will at least enable a solid measure of success across the majority develivery.