Software Development Plan Checklist

The product manager and tech lead draft a one-page scope: in-scope deliverables, explicit non-goals, target launch quarter, and rough budget. Non-goals are the part teams skip — name them. Park the doc in Confluence or Notion and link it from the project's Jira/Linear epic.

Name the responsible engineer(s), accountable EM/tech lead, consulted stakeholders (security, design, support), and informed parties (sales, CS). Ambiguity here is the most common reason architecture review stalls 4 weeks in.

Tier the project so downstream review depth scales appropriately. T-shirt size drives whether full architecture review and threat modeling are required, or whether the team can move faster with lighter ceremony.

Run a working session with PM, support, and at least one customer-facing engineer. Capture jobs-to-be-done, not solutions. Watch for the gotcha where sales-team requests get translated into spec without validation against actual customer behavior.

Spell out target SLOs (p95 latency, availability), expected request volume, data retention, accessibility (WCAG 2.1 AA if public-sector or EU), and any regulatory scope (HIPAA, PCI, GDPR, SOC 2). NFRs missed at planning surface as production fires.

Each story has Given/When/Then acceptance criteria a QA engineer can test against. Avoid stories larger than 5 points — break them down. "As a user I want X" without acceptance criteria is a known anti-pattern that pushes ambiguity into code review.

One ADR per significant choice: data store, API style (REST/gRPC/GraphQL), sync vs. async messaging, deployment topology. Include the alternatives considered and why they were rejected — future-you will thank present-you.

STRIDE walk-through with AppSec on the data flow diagram. Identify trust boundaries, authn/authz checkpoints, and PII flows. If the project handles PHI or cardholder data, this is a hard gate, not a checkbox.

Create the repo with CODEOWNERS, branch protection on main (required reviews, required status checks, no direct push), Dependabot or Renovate enabled, and secret scanning on. Trunk-based or GitHub Flow — pick one and document it in the README.

GitHub Actions or CircleCI workflow that runs lint, type check, unit tests, SAST (Semgrep or CodeQL), and SCA (Snyk or Dependabot) on every PR. Required-status-check ties into branch protection. "Just rerun, it's flaky" becomes a habit if you let it.

Set targets per layer: unit (Jest/pytest/RSpec) at 70-80%, integration at critical-path coverage, e2e (Playwright or Cypress) only on the top 5-10 user journeys. e2e-heavy pyramids become flaky and ignored.

If the project is in SOC 2 scope, confirm what change-management, access-review, and vulnerability-management evidence Vanta/Drata/Secureframe needs. Catching this at planning beats retrofitting audit trails six months in.

External pentest engagements book 4-6 weeks out. Schedule against the beta milestone, not GA — you need time to remediate findings before customer traffic.

Pick 2-3 SLIs (request success rate, p95 latency, freshness for async pipelines) and corresponding SLOs. The error budget makes the deploy-vs-stabilize tradeoff a number, not a debate.

RED dashboard (rate, errors, duration) per service plus the four golden signals. Alerts page only on user-impact symptoms — alerting on CPU at 80% is a known noise generator. PagerDuty routing tied to the on-call rotation.

Feature-flagged dark launch, then canary at 5% / 25% / 50% / 100%. Rollback plan covers reversing DB migrations (or marking them forward-only and shipping a kill switch instead) and pinning to the previous container image. Test the rollback path before the launch, not during.

Go/no-go meeting with EM, AppSec, support, and on-call. Walk the LRR checklist: SLOs configured, runbook published, pentest findings closed, support trained, rollback verified, status page templated.