Feature Lifecycle

Feature Lifecycle

Maps the full lifecycle of a feature from idea through production monitoring. Explicitly shows each role's contribution at each phase.

Domain Context

A feature doesn't live in isolation. It moves through distinct phases, and at each phase, a different role takes the lead:

The feature lifecycle is not linear. It may:

• Loop back (design issue found during development → redesign → reimplement)
• Iterate (deploy v1 → get feedback → plan v2 improvements)
• Split (feature splits into multiple parallel epics)

ISO/IEC 12207 Reference:

• 5.2.1 Stakeholder Needs and Requirements Definition
• 5.3 Technical Processes (design, implementation, verification, transition, operation)

Instructions

Step 1: Establish Feature Context

• Input: Feature name, problem statement, business goal
• Ask: Who's the primary PM? Architect? Security lead?
• Ask: What's the approximate scope? (small feature, large epic, infrastructure)
• Ask: Are there known constraints? (timeline, security, performance, compatibility)

Step 2: Ideation Phase

• PM: Articulates problem, potential solutions, business value
• Output: Problem statement, initial roadmap prioritization
• Next: Send to requirements planning

Step 3: Requirements Phase

• PM: Writes user stories, acceptance criteria, success metrics
• Architect: Assesses feasibility, identifies design complexity, dependency risks
• Security: Identifies threat surface, required security controls
• Designer: Scopes UX work, design systems integration
• Tech Lead: Estimates effort, identifies team skills, deployment strategy

Use /sdlc:definition-of-ready to validate requirements completeness

• Output: Requirements document (user stories, success metrics, acceptance criteria, DoR checklist)
• Exit: All DoR criteria met; ready to move to design

Step 4: Design Phase

• Architect: Decomposes system into components, documents trade-offs, creates architecture diagrams
• Security: Creates threat model (STRIDE), identifies mitigations, scopes security testing
• Designer: Creates wireframes, mockups, interaction patterns, accessibility plan
• Engineer: Participates in design review, identifies implementation risks
• Tech Lead: Reviews design for operational implications (monitoring, logging, scaling)

Use /sdlc:design-review to validate design cross-functionally

• Output: Design document (architecture, threat model, mockups, accessibility plan, trade-offs)
• Exit: Design approved by architect, security, designer; no blocking issues

Step 5: Development Phase

• Engineer: Implements code following the design, writes unit tests, participates in code reviews
• QA: Works with engineer on test strategy, preps test cases
• Tech Lead: Ensures code is maintainable, reviews code organization
• Designer: Ensures implementation matches design; flags mismatches

Use /sdlc:quality-gate to validate implementation meets design and code standards

• Output: Working code with unit tests, code review, implementation documentation
• Exit: Code review passed, unit tests passing, DoD implementation criteria met

Step 6: Testing Phase

• QA: Executes test strategy, reports bugs, validates fixes
• Engineer: Fixes bugs, works with QA on edge cases
• Security: Runs SAST/DAST scans, validates security controls
• Designer: Validates UI/UX match design on real implementation

Use /sdlc:quality-gate again to validate testing is complete

• Output: Test results, bug reports, security scan results
• Exit: All test cases passed, bugs fixed, security scan passed, test coverage adequate

Step 7: Deployment Phase

• Tech Lead: Orchestrates deployment, ensures rollback procedure is ready
• Engineer: Executes deployment steps, monitors for anomalies
• Operations: Monitors system health, readies for incident response
• PM: Prepares release communications, customer notifications

Use /sdlc:release-checklist to validate deployment readiness

• Output: Feature deployed to production, monitoring active, incidents ready
• Exit: Feature stable in production, no critical alerts, team trained

Step 8: Operations Phase

• Tech Lead: Monitors feature health, responds to incidents
• Engineer: Responds to bugs, works on post-launch improvements
• PM: Collects user feedback, observes success metrics
• Security: Monitors for security anomalies

Duration: Minimum 1-2 weeks; until stability is confirmed

• Output: Operational metrics, incident reports, user feedback
• Exit: Feature meets success metrics, no critical issues, team confident in stability

Step 9: Closure Phase

• PM: Validates success metrics, gathers user feedback, plans follow-up improvements
• Tech Lead: Facilitates retrospective, documents lessons learned
• Engineer: Archives technical docs, identifies debt to address
• Security: Reviews security incidents (if any), updates threat model if needed

Use /sdlc:retrospective-to-action to consolidate learnings

• Output: Retrospective document, action items, lessons learned, feature tagged as stable
• Exit: Feature is documented, team debriefed, backlog has follow-up items if needed

Step 10: Document the Feature Lifecycle

Create a feature lifecycle document:

Feature: [Name]
Problem: [User problem being solved]
Business Goal: [Expected impact]
Timeline: [Estimated dates for each phase]

Ideation: [PM drive, dates, decisions]
Requirements: [Stories, success metrics, DoR]
Design: [Architecture, threats, mockups, DoD]
Development: [Code, tests, documentation]
Testing: [Test results, bugs, fixes]
Deployment: [Release plan, rollback procedure]
Operations: [Stability period, incidents, metrics]
Closure: [Retrospective, lessons learned, follow-ups]

Key Milestones:

- Requirements approved: [date]
- Design approved: [date]
- Code complete: [date]
- Testing approved: [date]
- Production deployment: [date]
- Stability confirmed: [date]

Role Contributions:

- PM: Requirements, go/no-go decisions, success metric validation
- Architect: Design, trade-off analysis, scaling/performance review
- Security: Threat modeling, security testing, vulnerability management
- Engineer: Implementation, code quality, testing, deployment
- QA: Test strategy, test execution, bug triage
- Designer: UX design, accessibility, design system consistency
- Tech Lead: Orchestration, documentation, operational readiness

Post-Launch Actions: [Follow-up items, technical debt, process improvements]

Anti-Patterns

1. Skipping the operations phase

   • Mistake: "Feature is deployed, we're done"
   • Correct: Operations phase confirms stability; only then is it "done"
   • Fix: Require minimum 1-2 weeks of monitoring before closure

2. Not looping back on design issues found during development

   • Mistake: "The design says do X, but it doesn't work, so let's hack around it"
   • Correct: Design issues should trigger a design redesign, not implementation hacks
   • Fix: When development hits design issues, pause and redesign before implementing

3. Skipping the designer throughout the lifecycle

   • Mistake: "Designer was involved at the start, now engineering owns it"
   • Correct: Designer reviews implementation against design; catches mismatches early
   • Fix: Designer is involved in design phase → development QA → launch verification

4. Not including security until testing phase

   • Mistake: "Security review happens at the end"
   • Correct: Security is part of design (threat modeling); testing phase is too late
   • Fix: Security designs threat model in design phase; testing phase validates mitigations

5. Treating closure as optional

   • Mistake: "We shipped it, closing the ticket now"
   • Correct: Closure requires retrospective and lessons learned
   • Fix: Require closure ceremony; capture learnings for future features

Further Reading

• ISO/IEC 12207 — Software lifecycle processes
• Agile Release Train — SAFe, Program Increment Planning (https://www.scaledagileframework.com/)
• Feature Lifecycle — Reinertsen, D., "The Principles of Product Development Flow" (Celeritas Publishing)