SOP: Feature Development Lifecycle

Purpose

Standardize how a feature moves from ticket → code → review → merge → handoff, minimizing rework and lead time.

Scope

• Applies to all features & enhancements (bugs have their own SOP).
• Used by Developers, Tech Leads, PMs, and DevOps.
• QA runs as a separate track; this SOP ends at Dev→QA handoff.

Objectives

• Ensure tickets are well-specified before coding.
• Enforce clean branching, tests, and review.
• Create predictable, auditable delivery.

Step-by-Step Process

1) Intake & Grooming

1. PM/Lead drafts ticket with business goal and acceptance criteria.
2. Dev reviews feasibility; links to API/DB specs (EPIC 2 – Docs 4 & 5).
3. Size the work (S/M/L) and add dependencies.

Definition of Ready (DoR)

2) Plan & Design Trace

• Confirm design notes in ticket: edge cases, data model impacts.
• Create/update ADR if architecture choices are new (EPIC 2 – Doc 12).

3) Branching & Setup

• Branch from develop (or main if trunk-based).

Branch Naming

* Hotfix follows separate rollback SOP.

4) Build the Feature

• Write code with layered structure (controller → service → repo).
• Follow Service & Modularity Policy (EPIC 2 – Doc 7).
• Keep commits small, message format:
• type(scope): summary #TICKET
• Example: feat(export): add csv writer #WEB-142

Minimum Engineering Done

5) Local & CI Verification

• Run lint, unit, and integration tests locally.
• Push branch → CI must pass build, tests, security scans.

6) Pull Request & Review

• Open PR to develop (or main for trunk).
• PR Template (paste in description):

## What & Why
Summary + business context.

## Scope- What changed
- Not changed / out of scope

## Links
Ticket, design, API/DB docs, ADR.

## Testing- Unit: ...
- Integration: ...
- Manual steps: ...

## Risks & Rollback
Feature flag? Migration rollback steps?

Review Rules

7) Merge & Sync

• Squash or conventional merge per repo policy.
• Delete branch after merge.
• If monorepo: update affected workspaces and lockfiles.

8) Deploy to Staging

• CI/CD promotes build to staging automatically/manual-approve.
• Run smoke checks; confirm feature flag default.

9) Dev → QA Handoff (End of this SOP)

Attach this Handoff Note to the ticket and tag QA:

Dev→QA Handoff Template

(Full QA process lives in the separate QA SOP.)

Roles & Responsibilities

Governance

• DoR must be met before sprint commitment.
• No direct commits to protected branches.
• CI gates: lint, tests, security scan, build.
• Feature flags for risky/long-running features.
• Audit: PRs must link ticket & relevant docs.