Agile works on Salesforce, with adaptations.
Standard Scrum elements applied:
- Sprints — typically 2 weeks. Demos at end. Retrospectives.
- Backlog — user stories prioritised by Product Owner.
- Sprint planning — team commits to a sprint goal.
- Daily standup — 15 min, what I did, what I'm doing, blockers.
- Sprint review / demo — show working software to stakeholders.
- Sprint retrospective — what to improve.
Salesforce-specific adaptations:
1. Discovery first. Pure Scrum starts with a backlog and iterates. Salesforce projects need upfront Discovery and Solution Design. Treat as Sprint 0 (or several sprints) before Build sprints.
2. UAT can't always fit in a sprint. Some features need 2 sprints to build, then UAT. Plan UAT cycles separately.
3. Data migration is monolithic. Migration runs once at cutover; can't be sprinted incrementally.
4. Integrations have their own cycles. External systems' availability, schedules, and capacity drive integration timing.
5. Sandboxes complicate environments. Multiple sandboxes for different sprints/teams; refresh strategy matters.
6. Tests are mandatory. 75% Apex coverage required for production deploys; not "we'll write tests later".
7. Salesforce releases interrupt. 3 platform releases per year may force changes mid-sprint.
Tools:
- Jira for backlog/sprint tracking — most popular.
- Azure DevOps, GitHub Projects, Linear — alternatives.
- Salesforce DevOps Center for built-in version control.
- Gearset / Copado / Salto for deployment automation.
Anti-patterns:
- Waterfall in disguise — calling it Agile but doing Discovery for 6 months without iteration.
- No Product Owner — backlog drifts, priorities shift weekly.
- Sprints without demos — no validation; rework piles up.
- Demo without users — only project team in the room. Real users surface real issues.
Recommendation: hybrid is most common — waterfall structure for big phases, agile inside Build phase. Pure Agile rarely fits enterprise Salesforce contracts.