Project Delivery Framework

Overview

Sprint-based delivery approach for managing complex multi-stakeholder Salesforce projects. Emphasizes clear scope definition, stakeholder coordination, iterative delivery, and comprehensive quality standards.

Related Patterns:

• Testing Strategy - Comprehensive testing strategies
• Deployment Patterns - Deployment and CI/CD patterns
• Salesforce DX Patterns - SFDX-specific patterns
• Release Governance - Release approval and risk management

Sprint-Based Delivery

Sprint Structure

Pattern: Clear sprint definitions with defined scope

Implementation:

• Sprint 1, Sprint 2, etc. with defined scope
• Tracking of Salesforce configuration work within each sprint
• Integration testing milestones aligned with sprint deliverables
• Portal functionality delivered incrementally across sprints
• Clear scope definition and tracking to avoid scope creep

Sprint Planning

Practices:

• Define clear scope for each sprint with specific deliverables
• Track Salesforce configuration work, integration milestones, and portal functionality separately
• Align sprint deliverables with testing windows and stakeholder availability
• Communicate sprint scope clearly to all stakeholders
• Review and adjust sprint scope based on velocity and dependencies

Sprint Review Process

Comprehensive Analysis:

• Detailed feedback documents covering multiple areas
• Example: 18-point detailed feedback document covering:
  1. Logging pattern for HTTP callouts vs DataRaptor-only IPs
  2. NULL checks and error messages
  3. Silent failures and blank screens
  4. Hardcoded URLs - removal and configuration approach
  5. DataRaptor caching
  6. Test components
  7. Missing component descriptions
  8. Hardcoded test data and record IDs
  9. Naming convention - inconsistent naming
  10. Missing timeout settings for HTTP actions
  11. Apex classes used by Sprint 1 components
  12. Apex test classes
  13. Apex code quality - System.debug statements, hardcoded values, error logging
  14. Profile and Permission Set - security and configuration
  15. Feedback survey named flow not found in UI
  16. Data Dictionary - field type conversions, descriptions, naming standards
  17. Guest User Profile configuration
  18. SurveyResponse CreatedBy field - not reflecting actual submitter

Stakeholder Coordination

Stakeholder Groups

Groups:

• State IT teams for infrastructure and security requirements
• External integrators for integration platform work (MuleSoft, Boomi)
• Analyst partners for business analysis and requirements
• Internal teams for Salesforce configuration and development

Coordination Practices

Maintain:

• Regular communication with all stakeholder groups
• Keep everyone aligned on sprint scope and deliverables
• Coordinate testing windows across multiple systems and teams
• Document decisions and open items from stakeholder meetings
• Escalate blockers and dependencies promptly

Testing Window Coordination

Testing Milestones

Coordination:

• Reserved testing periods (e.g., December testing periods) for integration validation
• Coordination of testing schedules across multiple systems
• Alignment of testing milestones with sprint deliverables
• User acceptance testing (UAT) coordination with business stakeholders

Integration Milestone Tracking

Tracking:

• Track integration testing milestones separately from Salesforce configuration
• Coordinate integration testing with external integrators and external system teams
• Reserve testing windows for integration validation
• Document integration test results and issues
• Align integration milestones with sprint deliverables

Change Management

Documentation Alignment

Pattern: Keep technical design documents aligned with implementation

Practices:

• Discussions about when/how new objects and automations need to be reflected in technical design docs (TDD)
• Keeping diagrams and documentation aligned with actual implemented flows
• Version control for design documents and technical specifications
• Communication of changes to all stakeholders
• Review documentation regularly for accuracy

Change Communication

Practices:

• Communicate changes to all stakeholders
• Update TDD when implementations change
• Keep diagrams aligned with actual flows
• Version control all documentation
• Regular documentation reviews

Quality Standards

Comprehensive Code Review

Pattern: Rigorous code review process establishing comprehensive quality standards

Standards Established:

Error Logging Standards:

• ALL exceptions MUST be logged to custom log object using logging utility class
• NO System.debug statements in production code
• Use proper logging instead of System.debug

Error Handling Standards:

• Integration Procedures must show error messages to users when APIs fail
• Set failOnStepError: true for critical steps
• Add error states to Flex Cards
• Return error data in response

Configuration Management Standards:

• NO hardcoded values (IDs, counts, URLs, etc.)
• Use Custom Metadata or Custom Settings
• All URLs must use Named Credentials or Custom Metadata

Apex Code Standards:

• ALL Apex classes MUST have proper ApexDoc documentation
• ALL SOQL queries MUST use WITH SECURITY_ENFORCED or WITH USER_MODE
• ALL SOQL queries MUST be optimized (combine queries where possible)
• NO SOQL queries in loops
• ALL test classes MUST create their own test data (no @IsTest(SeeAllData=true))
• ALL test classes MUST achieve minimum 90% code coverage

Component Standards:

• ALL components MUST have meaningful descriptions
• NO test/dummy components in production
• Follow PascalCase naming convention
• Add timeout settings to HTTP actions
• Remove hardcoded test data

Data Dictionary Standards:

• Field descriptions must be meaningful (not just repeat label)
• Include: source, purpose, population, business rules
• Add help text for user-facing fields
• Convert Text fields with limited values to Picklists
• Standardize field naming patterns

Standards Documentation

Project Rules and Global Standards

Comprehensive Document: 1,000+ line standards document covering:

• Error logging, error handling, error message display
• Named Credentials usage
• Hardcoded URL prohibition
• Configuration management
• Component status and naming conventions
• Version management
• Performance optimization
• Security standards
• Documentation requirements
• Testing component standards
• Integration Procedure structure
• DataRaptor standards
• Apex code standards
• Profile and Permission Set standards
• Data Dictionary/Field standards

Best Practices

Sprint Management

• Define clear scope for each sprint
• Track deliverables separately by type
• Align with testing windows
• Communicate scope clearly
• Review and adjust based on velocity

Stakeholder Management

• Maintain regular communication
• Keep everyone aligned on scope
• Coordinate testing windows
• Document decisions and action items
• Escalate blockers promptly

Quality Assurance

• Establish comprehensive standards
• Conduct rigorous code reviews
• Document all standards
• Enforce standards consistently
• Review and update standards regularly

Documentation

• Keep documentation aligned with implementation
• Version control all documentation
• Update TDD when implementations change
• Communicate changes to stakeholders
• Review documentation regularly

Tradeoffs

Advantages

• Clear scope and deliverables
• Systematic quality standards
• Stakeholder alignment
• Iterative delivery
• Comprehensive documentation

Challenges

• Requires discipline and process
• Documentation overhead
• Coordination complexity
• Standards enforcement
• Change management complexity

When to Use This Framework

Use this delivery framework when:

• Complex multi-stakeholder projects
• Multiple integration points
• High quality requirements
• Government/compliance projects
• Large-scale implementations

When Not to Use This Framework

Avoid this framework when:

• Simple projects with single stakeholder
• No integration requirements
• Rapid prototyping needs
• Different methodology preferred
• Minimal quality requirements

Q&A

Q: What is a sprint-based delivery framework for Salesforce?

A: A sprint-based delivery framework manages complex multi-stakeholder Salesforce projects using iterative sprints. It includes: (1) Clear sprint definitions with defined scope, (2) Stakeholder coordination (aligning with multiple stakeholders), (3) Testing window coordination (scheduling testing with stakeholders), (4) Quality standards (comprehensive quality requirements), (5) Iterative delivery (incremental functionality delivery).

Q: How do I structure sprints for Salesforce projects?

A: Structure sprints by: (1) Defining clear scope for each sprint (specific deliverables), (2) Tracking work separately (Salesforce config, integrations, portal functionality), (3) Aligning with testing windows (schedule testing with stakeholders), (4) Delivering incrementally (portal functionality across sprints), (5) Avoiding scope creep (clear scope definition and tracking), (6) Reviewing and adjusting based on velocity and dependencies.

Q: How do I coordinate with multiple stakeholders?

A: Coordinate stakeholders by: (1) Identifying all stakeholders (who needs to be involved), (2) Defining roles and responsibilities (who does what), (3) Scheduling regular meetings (sprint planning, reviews, standups), (4) Communicating clearly (sprint scope, deliverables, timelines), (5) Managing dependencies (coordinate across teams), (6) Resolving conflicts (address disagreements promptly), (7) Keeping stakeholders informed (regular updates, status reports).

Q: How do I coordinate testing windows with stakeholders?

A: Coordinate testing by: (1) Scheduling testing windows (align with stakeholder availability), (2) Defining testing scope (what to test in each window), (3) Providing test environments (sandboxes, test data), (4) Communicating test requirements (what stakeholders need to test), (5) Collecting test feedback (structured feedback collection), (6) Addressing test issues (fix issues, retest), (7) Tracking test progress (monitor completion, blockers).

Q: What quality standards should I enforce?

A: Enforce quality standards: (1) Code quality (code reviews, static analysis), (2) Test coverage (minimum 75%, target 90%+), (3) Documentation (code comments, technical docs), (4) Security (security reviews, vulnerability scanning), (5) Performance (performance testing, optimization), (6) Accessibility (WCAG compliance for LWCs), (7) Compliance (regulatory requirements). Define standards upfront and enforce consistently.

Q: How do I manage change in a sprint-based framework?

A: Manage change by: (1) Defining change process (how to request changes), (2) Evaluating change impact (scope, timeline, resources), (3) Prioritizing changes (urgent vs. can wait), (4) Communicating changes (notify stakeholders), (5) Adjusting sprint scope (incorporate approved changes), (6) Tracking change requests (log all requests, decisions), (7) Balancing flexibility with stability (allow changes but control scope creep).

Q: When should I use a sprint-based delivery framework?

A: Use this framework when: (1) Complex projects (multiple stakeholders, integrations), (2) Multi-stakeholder coordination (need to align multiple teams), (3) Integration requirements (complex integrations need coordination), (4) Quality requirements (comprehensive quality standards needed), (5) Iterative delivery (incremental functionality delivery), (6) Change management (need structured change process).

Q: What are the tradeoffs of sprint-based delivery?

A: Tradeoffs include: (1) Advantages - structured approach, stakeholder coordination, quality standards, iterative delivery, (2) Challenges - more overhead, requires discipline, stakeholder availability, can be slower than ad-hoc, requires planning. Balance structure with flexibility based on project needs.

Q: How do I measure sprint delivery success?

A: Measure success by: (1) Sprint velocity (work completed per sprint), (2) Scope adherence (staying within sprint scope), (3) Quality metrics (test coverage, defect rates), (4) Stakeholder satisfaction (feedback, satisfaction surveys), (5) Timeline adherence (on-time delivery), (6) Change management (change request volume, handling), (7) Team velocity (improving over time).

Q: What are best practices for sprint-based delivery?

A: Best practices include: (1) Define clear scope for each sprint, (2) Coordinate stakeholders effectively, (3) Schedule testing windows with stakeholders, (4) Enforce quality standards consistently, (5) Manage change through structured process, (6) Communicate clearly (scope, deliverables, timelines), (7) Track progress (monitor velocity, blockers), (8) Iterate and improve (retrospectives, continuous improvement).

Related Patterns

• Testing Strategy - Comprehensive testing strategies covering integration testing, data quality testing, user migration testing, and UAT
• Deployment Patterns - Deployment and CI/CD patterns, source control strategies, Metadata API patterns
• Salesforce DX Patterns - SFDX project structure, commands, scratch org patterns, source tracking
• Release Governance - Change Advisory Boards, approval workflows, risk-based release checklists
• CI/CD Patterns - CI/CD automation, unlocked packages, sandbox seeding, rollback patterns