Feature Development Checklist

PM owns the PRD; tech lead reviews. Each story needs Given/When/Then acceptance criteria specific enough that QA can write test cases without follow-up questions. Attach the doc (Notion, Confluence, or Google Doc) here so the run has a permanent link.

Does the feature collect new PII, change data retention, expose new audit-log surface, or alter access control? Loop in security if any of those are yes — getting Vanta/Drata evidence retrofitted post-launch is painful. Note GDPR data-subject-rights impact if EU users are in scope.

Aim for stories under 3 points each — anything bigger usually hides ambiguity. Tag each story with the epic and the target sprint. Confirm capacity against the team's trailing 3-sprint velocity, not the optimistic estimate.

Cover the chosen architecture, the key API contracts, error handling, observability (which metrics, which logs, which traces), and rollback strategy. Name third-party services and the failure mode if they're down. Link to any related ADRs.

Forward-compatible only: new columns nullable, no destructive changes in the same release as code that depends on them. For tables over 1M rows, use ADD COLUMN (no default) + batched backfill + follow-up default — adding a defaulted column on Postgres rewrites the table under exclusive lock.

30-min review with tech lead and one senior engineer outside the project. Capture decisions and unresolved questions in the design doc. If the review surfaces material changes, do not start coding until the doc is updated and re-approved.

Create the flag with a named owner and a planned retirement date. Default off in production; on for internal users in staging. Record the flag key in the design doc so the post-launch cleanup step can find it.

Target PRs under 400 lines of diff — reviewers skim larger ones. Each PR should be independently mergeable behind the flag, even if the user-facing feature is incomplete. Avoid the long-lived feature branch anti-pattern; merge to main daily.

Required status checks must pass before merge — branch protection enforces this. "LGTM" without comments on a 400-line diff is a smell; ask for an explicit walk-through if the reviewer didn't leave any line comments.

Coverage target per the team's standard (commonly 80% line, but enforce on diff coverage rather than total). Integration tests cover the new API contracts end-to-end against a real DB. Mark any new flake-prone tests with retries and an owner — don't ship known flakes.

Cut a release candidate tag (e.g., v2024.45.0-rc.1) and run the full Playwright/Cypress suite in staging. Investigate any new failures; do not whitelist or skip them to unblock the release.

QA lead and tech lead together categorize each bug: blocker (ship-stopper), major (ship with known-issue note), or minor (file follow-up). Capture the count of remaining blockers below — anything over zero halts the release.

Push fixes, cut a new RC tag, re-run the e2e suite, and re-triage. Do not partially regression-test — bugs introduced by the fix are common. Loop back to the triage step until blockers reach zero.

Migrations go out ahead of the application code that depends on them, since old code must keep working against the new schema. Watch replication lag during the migration; abort and roll back if lag crosses the team's threshold (commonly 30s).

Route 5% of traffic to the new build for at least 10 minutes. Watch error rate, p99 latency, and saturation against the canary's own dashboard — comparing canary to baseline catches regressions that absolute thresholds miss.

Step through 25% → 50% → 100% with a monitoring pause at each stage. Frontend deploys after the backend is fully out, since the backend is forward-compatible by design.

The release captain stays primary on Datadog/Sentry alerts for 24 hours post-deploy. Compare error rate against the trailing 7-day baseline and the SLO error budget burn rate, not just absolute counts.

Release captain makes the call after the 24-hour soak. Criteria: error budget not burning faster than baseline, no SEV2-or-worse open against the feature, no customer-support spike. When in doubt, roll back — the cost of rollback is always less than the cost of a prolonged regression.

Flip the feature flag off first — that's the fastest and least risky rollback. If the regression is in code paths that ran regardless of the flag, redeploy the previous container image. The DB migration is forward-compatible, so it stays in place. Open a SEV2 incident and start the standard incident-response workflow.

Internal changelog goes to #engineering with the deployed sha. Customer-facing release notes (if user-visible) go through the standard PMM review and land in the docs site or in-app changelog.

Once the feature has been at 100% for at least a week with no rollback, remove the flag and the dead code paths. Stale flags compound — the team that defers cleanup ends up with 60+ flags and an exploding test matrix within 18 months.