Skip to content

Templates Library
What Copy-paste templates that make every process easy to follow consistently.
How to use Copy the block, fill it in, attach it to the relevant ticket or PR.

These are the reusable artifacts referenced throughout the playbook. Each is intentionally short. Adapt wording to your tool, but keep the required fields.

Definition of Ready

A story is ready for planning only when all of these are true:

  • Clear description of the requirement and the why.
  • Acceptance criteria, written so they are testable.
  • No blocking unknowns or unanswered questions.
  • Dependencies identified.
  • Rough size understood (enough to estimate).
  • Mapped to the correct JIRA Release.

Definition of Done

A story is done only when all of these are true:

  • Code complete on a feature or bug branch off the release branch.
  • Unit tests written and passing.
  • Static analysis quality gate passed (no new blocker or critical issues).
  • Pull request reviewed and approved by an assigned reviewer.
  • Merged into the release branch.
  • In-repo documentation updated in the same PR where behavior changed.
  • Acceptance criteria met and verifiable by QA.
  • Hours logged and ticket status accurate.

Pull request template

## What and why
<short summary of the change and the reason for it>

## Linked ticket
<JIRA ticket key, e.g. ABC-1234>

## Type
[ ] Feature  [ ] Bug fix  [ ] Refactor  [ ] Docs  [ ] Other

## How I tested
<unit tests added/updated, manual steps, environments>

## Static analysis
[ ] Quality gate passed locally (no new blocker/critical issues)

## Impact / risk
<areas this could affect beyond its stated scope>

## Checklist
[ ] Targets the correct branch (active release / hotfix)
[ ] Tests added or updated
[ ] In-repo docs updated if behavior changed
[ ] Reviewer assigned

Code review checklist

The reviewer confirms:

  • The change does what the ticket asks, and nothing unrelated.
  • Correctness: logic, edge cases, error and null handling.
  • Tests exist for new and changed behavior and actually assert it.
  • No new blocker or critical static-analysis issues; code smells within the gate.
  • Adheres to coding standards and fits the existing design.
  • No secrets, credentials, or sensitive data committed.
  • Risk to areas outside the stated scope is considered.
  • In-repo docs and diagrams updated where behavior changed.

Impact Analysis form

Filled by Development, supplied with the build, required before QA tests.

### Impact analysis of the change (not bugs)
1. Components impacted (select all): Frontend | Backend/API | Database | UI/UX | DevOps/Deployment
2. Functional impact: <new, modified, or removed functionality>
3. Technical impact: <affected modules, classes, functions, DB tables, APIs>

### Impact analysis of the bugs
1. Components impacted (select all): Frontend | Backend/API | Database | UI/UX | DevOps/Deployment
2. Functional impact: <key functional impacts>
3. Technical impact: <affected modules, classes, functions, DB tables, APIs>
4. Root cause of the issue: <what actually caused it>

Build Ticket template

The mandatory dev-to-QA handover. QA accepts a build only when this is complete.

## Build Ticket: BUILD-<id>

What this build represents: <short scope description>
Version: <vX.Y.Z, matching the JIRA Release>
Source branch: <release/vX.Y.Z>

Fixes and additions:
- <new / modified / removed item>
- ...

Impact analysis: <link to or inline the Impact Analysis form>

Build location:
- Mobile: <APK build URL>
- Backend: <deployment state and place, e.g. QA environment URL>

Resolved tickets in this build (linked):
- ABC-1234
- ABC-1240
- ...

Escalation information block

Gathered by Support before escalating an issue to Development.

SaaS Name:
SaaS URL:
Branch:
Branch Env:
Device Type:
Build Version:
Issue Platform:
Issue Detail:

Test plan skeleton

## Test plan: <release vX.Y.Z>
Build Ticket: BUILD-<id>
Impact analysis reviewed: [ ] yes

### Sanity (does the changed feature work on its main path?)
- [ ] <case>

### Smoke (do the main workflows still work end to end?)
- [ ] <critical journey>

### Regression (anything previously working now broken?)
Focused on impact-analysis areas: <modules>
- [ ] <case>

### Result
Defects logged against JIRA Release: <vX.Y.Z>
Go-ahead given: [ ] yes  by: <QA>  date: <>

Release notes template

# Release vX.Y.Z
Date: <>
JIRA Release: vX.Y.Z

## Added
- ...

## Changed
- ...

## Fixed
- ...

## Notes for Support
<anything client-facing Support should know before/after deploy>

Runbook template

For operational and deployment tasks; kept in the relevant repo.

# Runbook: <task name>
Purpose: <what this runbook accomplishes>
Owner role: <e.g. DevOps>

## Preconditions
- ...

## Steps
1. ...
2. ...

## Verification
- How to confirm success.

## Rollback
- How to undo if it fails.

## Related dashboards / logs
- Crashlytics / New Relic / Google Cloud Console links.

Incident report template

For production incidents and as the record behind an Escaped Defects Analysis.

# Incident / Escaped Defect Report
ID: <>
Date reported: <>     Date resolved: <>
Severity: Critical | High | Medium | Low

## Summary
<what happened, client impact>

## Detection
How was it found (client report / Crashlytics / New Relic / logs)?

## Resolution
What fixed it (normal release / hotfix vX.Y.Z)?

## Root cause
<technical root cause>

## EDA classification
[ ] Dev fault  [ ] QA fault  [ ] No fault / pre-existing  [ ] Edge case / out of scope
Reasoning (evidence based): <impact analysis, test plan, root cause>

## Prevention action
<test added / logging added / process change> (owner: <>)