Overview
Every project deserves a structured lifecycle, but most teams either over-engineer their process for small work or skip critical steps on large initiatives. I designed a universal project workflow that scales — a single framework that ensures the right SDLC gates are hit regardless of project size, while staying rooted in Agile principles.
The goal: one workflow that works for a two-sprint enhancement and a six-month platform migration alike.
The Problem
Organizations struggle with project consistency:
- Small projects skip steps — quick enhancements bypass discovery, jump straight to development, and surface defects in production
- Large projects drown in process — heavyweight methodologies slow delivery with unnecessary ceremony
- No standard intake — project requests arrive through email, Slack, Jira, hallway conversations, and meeting follow-ups with no consistent structure
- Inconsistent handoffs — requirements pass from BA to dev to QA differently every time, creating knowledge gaps
- Post-release gaps — teams ship and move on without retrospectives, knowledge transfer, or documentation updates
Design Philosophy
The workflow is built on three principles:
- Scale by depth, not by adding steps — every project hits the same gates, but the depth of work at each gate scales with complexity
- Agile-native — the workflow operates within sprint cycles, not alongside them
- Role-agnostic — the framework works whether you have a dedicated PM, a BA wearing multiple hats, or a dev lead managing delivery
Workflow Phases
1. Intake & Triage
Every project starts here — no exceptions. A structured intake captures:
- Problem statement and business justification
- Requesting stakeholder and sponsor
- Initial priority assessment (impact vs. effort)
- Preliminary scope boundaries
- Known dependencies and constraints
Scale lever: Small items get a single intake form. Large initiatives get a formal intake meeting with stakeholders.
2. Discovery & Requirements
Define what needs to be built and why:
- Stakeholder interviews and requirement elicitation
- Current-state analysis and pain point mapping
- User story creation with Gherkin acceptance criteria
- Process mapping (BPMN) for workflow changes
- Non-functional requirements (performance, security, compliance)
Scale lever: A UI tweak might need two user stories. A platform migration needs a full BRD with process maps and data flow diagrams.
3. Solution Design & Planning
Translate requirements into a delivery plan:
- Technical approach and architecture decisions
- Sprint planning and backlog grooming
- Dependency mapping across teams
- Risk identification and mitigation strategies
- Definition of Done alignment between BA, dev, and QA
Scale lever: Small work gets slotted into the next sprint. Large work gets a release plan with milestones.
4. Development & Iteration
Build in sprints with continuous validation:
- Sprint execution with daily stand-ups
- Ongoing BA availability for requirement clarification
- In-sprint demos and stakeholder feedback loops
- Scope management and change control
- Documentation updates in parallel with development
Scale lever: The sprint cadence stays the same — what changes is the number of sprints and the complexity of each increment.
5. Testing & Validation
Verify the build meets requirements:
- UAT planning and test case development from acceptance criteria
- UAT execution with structured defect tracking
- Regression testing for impacted workflows
- Stakeholder sign-off and go/no-go decision
- Performance validation against non-functional requirements
Scale lever: A small change might need a single UAT session. A major release needs a full test cycle with multiple rounds.
6. Release & Deployment
Ship with confidence:
- Release readiness checklist
- Communication plan for impacted users
- Rollback plan documentation
- Deployment coordination across teams
- Post-deployment verification
7. Closeout & Knowledge Transfer
Don't skip the ending:
- Retrospective — what worked, what didn't, what to change
- Documentation finalization and knowledge base updates
- Training materials for end users if applicable
- Metrics capture — delivery timeline, defect rates, stakeholder satisfaction
- Lessons learned documented for future projects
Why One-Size-Fits-All Works
The key insight is that the phases are universal — every project needs intake, requirements, planning, building, testing, releasing, and closing. What changes is the depth at each phase:
| Phase |
Small Enhancement |
Large Initiative |
| Intake |
Form submission |
Formal meeting |
| Discovery |
2–3 user stories |
Full BRD + process maps |
| Planning |
Sprint slot |
Multi-sprint release plan |
| Development |
1 sprint |
4–8 sprints |
| Testing |
Quick UAT |
Full test cycle |
| Release |
Standard deploy |
Coordinated release |
| Closeout |
Brief retro |
Full retrospective + KT |
What I Learned
- Process frameworks fail when they're all-or-nothing — scalability is the key to adoption
- Teams adopt workflows when the framework reduces overhead instead of adding it
- The intake phase is the most commonly skipped and the most impactful — a bad intake creates downstream problems that compound
- Retrospectives and closeout are where most teams cut corners, but they're where the most organizational learning happens
- Agile and structured SDLC are not opposites — the sprint is the delivery mechanism, and the lifecycle is the quality mechanism
Updates
2026-03-27 — All seven workflow phases documented with scale levers.