Why this matters: the blank page is the real reason acceptance criteria go unwritten. Pre fill the structure and the work becomes filling in boxes. Load these as work item templates in Azure DevOps Setup so a new item is created with the shape already there.
Epic
Written as a business objective, per Work Breakdown Hierarchy.
# Epic: <business objective in plain language>
**Why now:** <what changes for the business if we do this>
**Who it serves:** <which users or segment>
**Success looks like:** <the measurable outcome, if you can name one>
**Features in scope**
- <capability 1>
- <capability 2>
**Explicitly not in scope**
- <things people will assume are included, named so they are not>
**Open questions**
- <question> | owner: <name> | needed by: <date>
Feature
# Feature: <capability name a customer would recognise>
**Parent Epic:** <link>
**Owner:** <name>
**What it lets a user do:** <one or two sentences>
**Why it matters:** <the reason>
**Stories**
- <story 1>
- <story 2>
**Dependencies:** <other features, external services, data migrations>
**Out of scope:** <named exclusions>
User Story
The one that matters most. Craft notes in Writing User Stories and Acceptance Criteria.
# <short outcome title>
As a <specific role>
I want <capability>
So that <benefit>
## Acceptance criteria
1. Given <state>, when <action>, then <observable result>.
2. Given <state>, when <action>, then <observable result>.
3. <rule or constraint stated as a checkable fact>
4. <error case>
5. <permission or boundary case>
## Out of scope
- <thing that will come up at the demo, named now>
## Notes
- <design link, constraint, the subtle case worth flagging>
## Open questions
- <question> | owner: <name>
Task
# <verb + object, e.g. "Add stock check to invoice save">
Parent story: <link>
Remaining work: <hours, if you track them>
What this covers: <one line>
Done when: <the specific technical outcome>
Keep it to a day or less. If it is bigger, split it.
Bug
# <what is wrong, from the user's point of view>
**Severity:** critical / high / medium / low
**Found in:** <environment, version>
**Affects:** <feature, and roughly how many users>
## Steps to reproduce
1.
2.
3.
**Expected:** <what should happen, quoting the acceptance criterion if there is one>
**Actual:** <what happens>
**Evidence:** <screenshot, log, request id>
**Related story:** <link to the Story that introduced or owns this behaviour>
That last line is what lets you later ask which features generate the most defects, which is how you prioritise coverage in Test Case Strategy.
Spike
# Spike: <question to answer>
**Timebox:** <n days, hard stop>
**Question:** <the single decision this must inform>
**Output:** <a one page recommendation / a working throwaway prototype / a sizing>
**Options to evaluate**
- <option a>
- <option b>
**Decision criteria:** <cost, effort, risk, fit with existing system>
A spike ends with a decision, not a feature. If it produces code, the code is throwaway unless explicitly decided otherwise.
Definition of Ready checklist
Adapt from Definition of Ready. Keep it to seven items.
- [ ] Business reason is clear
- [ ] Written as a small user or business outcome
- [ ] Acceptance criteria written, including the main error cases
- [ ] Dependencies identified
- [ ] Design or mockup available if there is UI
- [ ] Major unknowns investigated or spiked
- [ ] Estimated, and fits comfortably in one sprint
Definition of Done checklist
Adapt from Definition of Done. Start with version 1 and grow it.
- [ ] All acceptance criteria pass
- [ ] Code reviewed by another person
- [ ] Unit tests written and passing
- [ ] Test cases written and linked to the story
- [ ] Integration tests passing, CI green
- [ ] Merged and deployed to test
- [ ] No known critical or high severity defects
- [ ] Documentation updated where behaviour changed
Test case
TC-<AREA>-<NNN> <what this proves, in one line>
Precondition: <starting state, specific data>
Steps: 1. <action>
2. <action>
Expected: <observable result, specific enough to be unarguable>
Traces to: Story #<id>, acceptance criterion <n>
Type: manual / automated
Feature one pager
The maintenance record, explained in Feature Inventory and Ownership.
# Feature: <name>
**Owner:** <name> **Last reviewed:** <date> **Status:** live / deprecated
## What it does
## Why it exists
## Expected behaviour
## Edge cases we know about
## What it depends on
## How it is tested
## Known gaps
## Decisions worth remembering
<date>: chose X over Y because Z. Do not undo without solving Z.
Sprint Goal
Sprint <n> goal: <one sentence describing the single outcome>
We will know we achieved it when: <the demonstrable thing>
Not in this sprint: <the thing people will ask for anyway>
Written before selecting items, per Sprint Planning and Refinement.
Feedback triage card
Keep this visible during the sprint. Full reasoning in Feedback and Scope Control.
Feedback received. Which is it?
□ Defect → does not match agreed criteria → fix in this story
□ Clarification → criteria were misread → correct in this story
□ New scope → capability nobody agreed to → NEW backlog item
□ Requirement change→ the business need itself changed → PO decides, deliberately
□ Urgent production → customers affected now → take it, REMOVE equal work
□ Nice idea → came out of the demo → backlog, prioritise later
Only the first two belong inside the current story.
Retrospective carry over analysis
Instead of “why did we not finish”, ask this per unfinished item:
Item: <title> Points: <n>
Cause (pick one):
□ Scope added after the sprint started
□ Requirement was unclear when we started
□ Blocked by a dependency
□ Genuinely harder than anyone could know
□ Unplanned production work consumed the time
□ We simply took on more than our velocity supports
Evidence: <one line>
Tally the causes across three sprints and your improvement priority stops being a matter of opinion. The four common misdiagnoses are listed in Estimation and Story Points.